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Welcome to the new improved loginl 

Last summer, the executive director and I 
proposed to the usenix Board of Directors that 
we add a technical editor to strengthen the As¬ 
sociation’s newsletter, which is the main commu¬ 
nication pipeline to its members. As is often the 
case, the person making the suggestion was asked 
to own the problem. So, here is the first issue of 
login with new features. 

I believe that login should be something that 
people look forward to receiving each month. It 
should have announcements, calendars, news 
from other organizations, books reviews and stan¬ 
dards reports (features that that have been its 
hallmark of the past) and more. 

In 1988, usenix began publishing the Stan¬ 
dards Reports—a major step forward in the tech¬ 
nical content of login . These reports have been 
very well-received—both within and outside of 
the standards community. The reporters and ed¬ 
itors have done an incredible job of keeping our 
membership (and the standards committees) in¬ 
formed of the goings-on at the various meetings. 
This effort is proof that login can reach wide 
audiences with meaty technical information. 

Recently, I embarked on a quest to find 
contributors—people who would commit (for one 
year) to write several pieces for login. The articles 
should be breezy, just a page or two, and easy to 
read in the odd spare moment or in the reading 
room. I was looking for writing in both the strict¬ 
est technical sense and also reviews—of books, of 
software, of hardware, or anything else of interest 
to our members. 

The response has been terrific! A total of 59 
people have committed to contributing at least at 


the ‘casual’ level. This month brought 18 submis¬ 
sions, of which about half are printed here (space 
was consumed quickly this issue). As the page 
counts evolve and the organizational announce¬ 
ments are compressed, you’ll see more short and 
medium-length technical articles. You may not 
like every one of them (e.g., not everyone cares 
about the internals of some complicated parser), 
but it is my hope that most everyone will like the 
majority of them. 

This is only the beginning of the changes. In 
addition to providing more technical content, 
Carolyn Carr, our Managing Editor, is doing a 
makeover and facelift for the newsletter’s inte¬ 
rior. The new design will be ready later this year, 
and we hope it will make the newsletter more 
readable. 

Are you interested in contributing one, two, 
three or even six articles per year? If so, please 
contact me (Rob Kolstad, 719-593-9445, 
kolstad@bsdi.com) and I’ll send you the infor¬ 
mation I’ve assembled. If there’s something you’d 
like to see published (e.g., a question about NFS 
automounters or a short article on floating point 
performance), then write me so I can add it to the 
list of technical suggestions that circulates to our 
writers every month. 

If you have special editorial views that you 
wish to air, please submit them as well. I will do 
my best to get a balancing point of view and 
publish the pieces under ‘Controversy’. 

Enjoy the new rag! 

Rob 


March/April 1992 
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Preliminary Program: 

Workshop on Micro-kernels and Other Kernel Architectures 
Seattle, WA, April 27-28, 1992 


This workshop is aimed at comparing and 
contrasting existing micro-kernels and their 
macro-kernel counterparts. Industry pundits are 
claiming that microkernel technology is the next 
step in kernel design. This workshop intends to 
make a detailed technical investigation of the mi¬ 
crokernel technology to discover whether the 
claims have merit or are just this year’s buzz 
word. We will also identify micro-kernels 
strengths and weakness in comparison to each 
other and to the macro-kernels that they hope to 
replace. The comparisons will include function¬ 
ality, modularity, ease of extension, maintainabil¬ 
ity, and performance. 

Monday, April 27, 1992 

The first day of the workshop will be largely 
devoted to talks of a tutorial nature on currently 
important microkernels and other kernels. 

8:30-8:35 Opening Remarks (Lori Grob) 

8:35-9:35 Amoeba, Robbert van Renesse 

(Vrije University/Comeli) 
9:35-10:35 Mach, Richard Draves (Carnegie 
Mellon University) 

11:05-12:05 Plan 9, David Presotto (AT&T Bell 
Laboratories) 

1:30-2:30 Chorus, Marc Rozier (Chorus syste- 
mes) 

2:30-3:30 NT, David Cutler (Microsoft Corp.) 

4:00-5:00 Microkernels Panel Session 
Moderator: Peter Honeyman (CITI University of 
Michigan) What is a microkernel? Are there 
really any differences? 

5:00-6:00 New Architectures 
(Chair: TBA) Modularity and Interfaces in Micro¬ 
kernel Design and Implementation 

A Case Study of Chorus on the HP-PA Rise 
Jonathan Walpole, Jon Inouye, Ravindranath 
Konura 

Dept, of Comp. Science and Engineering, Oregon 
Graduate Institute of Science and Technology 

A Micro-Kernel Architecture for Next Genera¬ 
tion Processor 


Toshio Okamoto, Hideo Segawa, Sung Ho Shin, 
Hiroshi Nozue, Toshiba Corporation Informa¬ 
tion Systems Lab 

Tuesday, April 28 

8:30-10:30 New Systems 
(Chair: Robbert van Renesse) 

The KeyKOS(R) Nanokemel Architecture 
Allen C. Bomberger, William 5. Frantz, Ann C. 
Hardy, Norman Hardy, Charles R. Landau, 
Jonathan S. Shapiro, Key Logic Corp. 

An Architectural Overview of QNX 
Dan Hildebrand, Quantum 

An Architectural Overview of Alpha: A Real- 
Time, Distributed Kernel 
Franklin Reynolds, Open Software Foundation 

The BirLix Operating System and Its Perfor¬ 
mance 

P. Schuller, H. Hartig, W.E. Kunhauser, German 
National Research Center For Computer Sci¬ 
ence (GMD) 

11:00-12:30 Lessons Learned 
(Chair: Edward Lazowska) 

Multimedia/Realtime Extensions for Mach 3.0 
Jun Nakajima, Masatomo Yazaki, Hitoshi Mat- 
sumoto, Human Interface Laboratory #1 Fu¬ 
jitsu Laboratories Ltd. 

Reimplementing the Synthesis Kernel 
Henry Massalin, Calton Pu, Department of Com¬ 
puter Science, Columbia University 

A Model and Prototype of VMS Using the Mach 
3.0 Kernel 

Cheryl A. Wiecek, Digital Equipment Corpora¬ 
tion 

2:00-3:30 Experience and Observations I 
(Chair: Lori S. Grob) 

The Increasing Irrelevance of IPC Performance 
for Microkernel-Based Operating Systems 
Brian Bershad, School of Computer Science, Car¬ 
negie Mellon University 
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Fast Thread Management and Communication 
Without Continuations 

Jochen Liedtke, German National Research Cen¬ 
ter for Computer Science (GMD) 

Experience with SVR4 Over Chorus 
Barry Glees on, Jim Hamrick, Scott Lurndal, Dar¬ 
ren Price, Jim Soddy, Unisys Corp. 

4:00-6:00 Experience and Observations II 

(Chair: Avadis Tevanian ) 

Data Movement in Kernelized Systems 
Randall W. Dean, Francois Armand, CMU, Cho¬ 
rus systemes 

Distributed Abstractions, Lightweight Refer¬ 
ences 

Marc Shapiro, Mesaac Makpangou, INRIA 

Reliable Multicast between Micro-Kernels 
Robbert van Renesse, Ken Birman, Robert Coo¬ 
per, Bradford Glade, Patrick Stephenson, 
Cornell University 

File Systems Workshop 

Ann Arbor, Michigan, May 21-22, 

The goals of this workshop are to bring to¬ 
gether researchers and practitioners on all aspects 
of file systems, including: 

• file system performance measurement and 
models; 

• WORM and other optical systems; 

• log-structured, RAID, and other high- 
performance systems; 

• mass-storage and archival systems; 

• replication, consistency, and mobility, as 
they relate to file systems; 

• naming and location in very-large distrib¬ 
uted file systems. 

Workshop participants will present formal 
papers and informal works-in-progress. We will 
identify and discuss trends, themes, and theoret¬ 
ical and practical aspects of file systems research 
and development. 


Clustering Micro-Kernels for Scalability 
Michael Stumm, Ronald Unrau, and Orran 
Krieger, Department of Electrical Engineering, 
University of Toronto 

Program Committee: 

Lori S. Grob, Program Chair 
Chorus systemes 

Edward D. Lazowska 
University of Washington 

Robbert van Renesse 

Cornell University/Vrije Universiteit 

Avadis Tevanian, Jr. 

NeXT Computer, Inc. 

For registration information please contact 
the usenix Conference office. 


1992 

Pre-registration materials containing the pro¬ 
gram and hotel reservation information will be 
mailed to the usenix mailing list early April, 
1992. If you did not receive this announcement 
directly and wish to be on the list for receipt of 
these materials, please contact: 

usenix conference Office 
22672 Lambert St. 

Suite 613 

El Toro, CA 92630 
+ 1 714 588 8649 
conference@usenix.org 

Program Committee: 

Peter Honeyman (CITI) 

Michael L. Kazar (Transarc) 

Larry McVoy (Sun) 

Mendel Rosenblum (Stanford) 

Liuba Shrira (MIT) 


March/April 1992 
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USENIX Summer 1992 Technical 
San Antonio, TX, June 8-12, 1992 

Tutorials 

Monday, June 8, 1992 

NEW! Using, Managing, and Implementing NFS 
Ralph Droms, Bucknell University 

Network Security: The Kerberos Approach 
Dan Geer, Geer Zolot Associates, Jon A. 
Rochlis, MIT 

The Internet & its Protocols 

William LeFebvre, Northwestern University 

System V Release 4.0 Internals 
Part 1: Virtual Memory & File Systems 
Mike Scheer, ProLogic Corporation and Steve Bu- 
roff, AT&T 

OSF/1 Internals 

Thomas W. Doeppner, Jr., Brown University 

Topics in Advanced System Administration, 1992 
Trent Hein, XOR Computer Systems, Dr. Rob 
Kolstad, Berkeley Software Design, Inc., Dr. 

Evi Nemeth, University of Colorado, Boulder 

NEW! Recent Developments in Designing & 
Evaluating Trusted Products & Systems 
Marshall D Abrams, The MITRE Corporation 

NEW! Using the Shell as an Application Devel¬ 
opment Language 

Ray Swartz , Berkeley Decision/Systems 

NEW! Introduction to Threads & Threads Pro¬ 
gramming 

Nawaf Bitar, Kubota Pacific Computer 


Tuesday, June 9, 1992 

Distributed File System Administration with AFS 
& DCE DFS 

Linda Walmer, Phil Hirsch, Transarc Corpora¬ 
tion 

Topics in UNIX System Security 
Matt Bishop, Dartmouth College 

UNIX Network Programming 
Richard Stevens, Consultant 


Conference 


System V Release 4.0 Internals Part 2: Selected 
Topics 

Steve Buroff, AT&T, Mike Scheer, ProLogic 
Corporation 

Exploiting the X Window System: Xlib & Xt 
Oliver Jones, PictureTel Corporation 

NEW! Essentials of Practical Perl Programming 
Tom Christiansen, CONVEX Computer Corpo¬ 
ration 

An Introduction to C++ 

Robert Murray, AT&T Bell Labs 

4.4BSD Preview: Kernel Internals 
Marshall Kirk McKusick, UC Berkeley, 
Michael J. Karels, Berkeley Software Design, 
Inc. 

NEW! Half day (morning) 

Preparing for Disaster 

Brent Chapman, Great Circle Association 

NEW! Half day (afternoon) 

Managing the Domain Name System 
William LeFebvre, Northwestern University 

Preliminary Technical Program 

Wednesday, June 10 

9:30-10:30 Opening Remarks 

Rick Adams, UUNET Technologies, Inc. 

Keynote Address 
Stuart Feldman, Bellcore 

11:00-12:30 Threads 

Session Chair: David Nichols, Xerox PARC 

Implementing Lightweight Threads 
D . Stein, D. Shah, SunSoft Inc. 

Beyond Multiprocessing: Multithreading the Sys¬ 
tem V Release 4 Kernel 
J.R. Eykholt, S.R . Kleiman, S. Barton, R. 
Faulkner, D. Stein, M. Smith, A. Shivalingiah, 
J. Voll, M. Weeks, D. Williams, SunSoft Inc. 

File System Multithreading in System V Release 
4 MP 

J . Kent Peacock, Intel Multi-Processor Consor¬ 
tium 
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11:00-12:30 Invited Talk: Rules of Thumb for 
System Administrators 

Steve Simmons, Industrial Technology, Elizabeth 
D. Zwicky, SRI Inti. 

2:00-3:30 Performance Art 

Session Chair: Margo Seltzer , University of 
California, Berkeley 

The Recovery Box: Using Fast Recovery to Pro¬ 
vide High Availability in the UNIX Environ¬ 
ment 

Mary Baker y Mark Sullivan, UC Berkeley 

On Migrating a Distributed Application to a Mul¬ 
tithreaded Environment 

Thuan Q. Pham y Pankaj K. Garg y Hewlett- 
Packard Laboratories 

Cheap Mutual Exclusion 

William Moran Jr. y Farnam Jahanian y IBM T.J. 
Watson Research Center 

2:00-3:30 Invited Talk: Cables Have More Than 
Two Ends 

Nat Howard , Bellcore 

4:00-5:30 Applications 

Session Chair: Jim Thompson y Smallworks, Inc. 

TDBM: A DBM Library With Atomic Transac¬ 
tions 

Barry Brachman, Gerald Neufeld y University of 
British Columbia 

Developing a Network Version of Grateful Med 

Kevin Brook Long , Gerald Fowler y Stan Barber, 
Baylor College of Medicine 

InterNetNews: Usenet Transport for Internet 
Sites 

Rich Salz, BBN Systems and Technologies 

4:00-5:30 Invited Talk: Overview of ML 

Andrew Koenig , AT&T Bell Laboratories 

Thursday, June 11 

9:00-10:30 Virtuality 

Session Chair: Kenneth Ingham y Kenneth Ingham 
Consulting 

Tiled Virtual Memory for UNIX 

James W. Franklin, Kodak Electronic Printing 
Systems 

A Scalable Implementation of Virtual Memory 
HAT Layer for Shared Memory Multiprocessor 
Machines 


Ramesh Balan y UNIX System Laboratories, Inc. 

Virtual Window Systems: A New Approach to 
Supporting Concurrent Heterogeneous Win¬ 
dowing Systems 

Rita Pascale, Jeremy Epstein y TRW Systems Di¬ 
vision 

9:00-10:30 Invited Talk: Do You Trust Your 
Floating Point? 

Norm Schryer , AT&T Bell Laboratories 
11:00-12:30 

Session Chair: Bill Cheswick , AT&T Bell Labo¬ 
ratories 

Invited Talk: UNIX on my Mind 

M. Douglas Mcllroy , AT&T Bell Laboratories 

2:00-3:30 Planning for Failure 

Session Chair: A. Elein Mustain y Ingres 

A Discipline of Error Handling 

Doug Moen y Sietec Open Systems Division 

Regression Testing and Conformance Testing In¬ 
teractive Programs 
Don Libes y NIST 

NED: The Network Extensible Debugger 
Paul Maybee , Solbourne Computer, Inc. 

2:00-3:30 Invited Talk: Self-Help on the Net 
Jeff Kellem y Beyond Dreams 

4:00-5:30 Performance & Availability 
Session Chair: Keith Bostic, CSRG, UC Berkeley 

Real-Time Disk Storage and Retrieval of Digital 
Audio/Video Data 

David P. Anderson, Yoshitomo Osawa , Ramesh 
Govindan y UC Berkeley 

Mainframe Services from Gigabit-Networked 
Workstations 

F. Hemmer y E. Jagel y A. Kumar y L. Robertson , 
B. Segal, A. Trannoy, CERN 

A Highly Available Lock Manager For HA-NFS 
Anupam Bhide, IBM T.J. Watson Research 
Center, Spencer Shepler, IBM Austin 

4:00-5:30 Invited Talk: UNIX, Commercial Soft¬ 
ware, and the X Window System 
Gary Aitken, Solbourne Computer, Inc. 

Friday, June 12 

9:00-10:30 CPP: Threat or Menace? 
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Session Chair: Judith E. Grass, AT&T Bell Lab¬ 
oratories 

#ifdef Considered Harmful or Portability Expe¬ 
rience With C News 

Henry Spencer , University of Toronto, Geoff 
Collyer, Software Tool & Die 

Inch A Tool to Analyze Include Files 

Kiem-Phong Vo, Yih-Farn Chen , AT&T Bell 
Laboratories 

Large Scale Porting through Parameterization 

David Tilbrook, Russell Crook , Siemens Nixdorf 
Information Systems Ltd. 

Invited Talk: Secure Networking 

Bill Griffeth, UNIX System Laboratories, Inc. 

Work-in-Progress Reports 

11:00-12:30 

Session Chair: Rob Kolstad , Berkeley Software 
Design, Inc. 

Invited Talk: The Great usenix Tool-Off 

Organized by Ed Gould , Digital Equipment Cor¬ 
poration 


2:00-3:30 System Administration 

Session Chair: Guy Harris , Auspex Systems, Inc. 

Performance of a Parallel Network Backup Man¬ 
ager 

James da Silva , Olafur Gudmundsson, Daniel 
Mosse, University of Maryland 

The DIDS (Distributed Intrusion Detection Sys¬ 
tem) Prototype 

Steven R. Snapp, Stephen E. Smaha, Daniel M. 
Teal, Haystack Laboratories, Inc. 

A Privilege Mechanism for System V Release 4 
Operating Systems 

Charles Salemi, Eric Lund, Suryakanta Shah , 
Unix System Laboratories, Inc. 

2:00-3:30 Invited Talk: What is ASN.l? 

Kwong Fung, UNIX System Laboratories, Inc. 

4:00-5:30 Miscellany 

Session Chair: Margo Seltzer , UC Berkeley 

TCP/IP and OSI Interoperability with the X Win¬ 
dow System 

Nancy Crowther, Joyce Graham , IBM Cambridge 
Scientific Center 

More Work-in-Progress Reports 


Our Area Code has Changed 


Please note that as of mid-January 1992 the 
usenix Association executive office area code 
phone number changed from 415 to 510. Tele¬ 
phone: 510/528-8649 Fax: 510/548-5738 
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Tutorial Registration Fees 

The tutorial registration fee includes the 
following: 

• Admission to the tutorial(s) you select 

• Copy of bound tutorial materials for your 
session(s) 

• Box lunch 

• Paper and pen 

TUTORIAL REGISTRATION FEE SCHEDULE 

• Pre-registration (before May 18, 1992) 


Two full-day or one full-day & two 

half-day tutorials.$445 

One full-day or two half-day 

tutorials.$245 

Each half-day tutorial.$150 

• Registration (after May 18, 1992) 

Two full-day or one full-day & two 

half-day tutorials.$495 

One full-day or two half-day 

tutorials.$295 

Each half-day tutorial.$200 


4-*-fr 

Special Note For 
Full-time Students 
YOUR IMMEDIATE ATTENTION IS REQUESTED! 

A limited number of spaces in each tutorial are 
reserved for full-time students at the special fee 
of $50.00 per tutorial. You MUST telephone the 
USENIX Conference Office, (714) 588-8649 dur¬ 
ing office hours of 8:30 am - 5:00 pm Pacific 
Time Monday - Friday, to confirm availability 
and make a reservation. You will receive a reser¬ 
vation code number. This number MUST appear 
on your Registration Form. Your registration 
form with full payment and a photocopy of your 
current student I.D. card MUST arrive within 14 
days from the date of your reservation. If your 
registration form and payment do not arrive by 
that date, your reservation will be cancelled. 
This special fee is non-transfer able. 

Enjoy the Benefits of Becoming 
a USENIX Member 

You may designate $65 of your non-member 
Technical Sessions registration fee as dues in full 
for a one-year Individual USENIX Association 
membership. Just check the special box on the 
Registration Form requesting membership. 

As a member of the USENIX Association, your 
benefits include: 

• Free subscription to /login:, bi-monthly 
newsletter 

• Free subscription to Computing Systems, 
a refereed technical quarterly published 
for the Association by the University of 
California Press 

• Discounts on Association-sponsored 
bi-annual conferences and frequent 
workshops and symposia addressing 
special interest topics 

• Updates on and a voice in various 
ANSI, IEEE and ISO standards efforts 

• Participation in leadership in the UNIX 
community 


Registration 
Information 
and Fees 

USENIX 
Summer 1992 
Technical 
Conference 



FOR ADDITIONAL CONFERENCE 
OR REGISTRATION INFORMATION. 
PLEASE CONTACT: 

USENIX CONFERENCE OFFICE 
22672 LAMBERT ST., SUITE 613. 

EL TORO. CA 92630 USA 

TELEPHONE: (714) 588-8649 
FAX: (714) 588-9706 

EMAIL: conferences usenix.org 

OFFICE HOURS: 

8:30 AM - 5:00 PM PACIFIC TIME 


Technical Sessions 
Registration Fees 

The technical sessions registration fee includes 
the following: 

• Admission to all technical sessions 

• Copy of Summer 1992 Conference 
Proceedings 

• Copy of Invited Talks Submitted Notes 

• Admission to the USENIX Reception at 
La Villita 

TECHNICAL SESSIONS REGISTRATION 
FEE SCHEDULE 

• Pre-registration fee (before May 18, 1992) 


'Member Non-Member Student 

$255 $320 $75 

• Registration fee (after May 18, 1992) 
'Member Non-Member Student 

$305 $370 $75 


*The member rate applies to current indi¬ 
vidual members of the USENIX Association, 
Sun User Group, EurOpen and AUUG. 

Payment 

• Fees are payable to USENIX Conference 
by check, VISA, MasterCard or American 
Express. 

• To be processed, payment must accom¬ 
pany your completed Registration Form. 

• Registration by telephone is not 
permitted. 

• Purchase Orders and vouchers CANNOT 
BE accepted. 

• You may FAX your Registration if 
payment is by credit card, (To avoid 
duplicate billing when faxing your 
registration, do not mail an additional 
copy to the Conference Office.You may 
telephone our office to confirm receipt of 
your fax.) 

Cancellation/Refund Policy 

If you must CANCEL, all refund requests must 
be in writing and postmarked no later than 
June 1, 1992. Cancellations cannot be taken 
over the telephone. 

If you have registered but are unable to attend, 
you may telephone to substitute another in your 
place. 

-D-4-4- 

Register Early to Save! 

Tutorial and technical session fees each increase 
$50 after May 18, 1992. 


Photo: The San Antonio Marriott Rivercenter 
with the Alamo in the foreground. 












If you don't want the address you are 
providing to be used for all future 
USENIX mailings, check here: □ 

If you do not want to appear in the 
attendee list, check here: □ 

Is this your first USENIX Conference? 

□ Yes □ No 

Are you a current USENIX member? 

□ Yes □ No 

If not, you may wish to join. See below.* 
Are you (please check only one): 

1. □ Academic (Student or Faculty) 

2. □ Computer Operations/Systems 

Administration staff 

3. □ Computer Operations/Systems 

Administration management 

4. □ Engineering/Research/Software 

Development staff 

5. □ Engineering/Research/Software 

Development management 

6. □ Other staff 

7. □ Other management 


Registration Form 

USENIX 

Avsooation 

Technical 

Conference 

JUNE 8-12 1992 


SAN ANTONIO TEXAS 



Important! 

• Please type or print clearly. 

• Please duplicate this form as needed. 

• Please complete this form and return it along 
with your full payment to: 

USENIX CONFERENCE OFFICE 
22672 Lambert Street, Suite 613 
El Toro, CA 92630 
(714) 588-8649 
FAX: (714) 588-9706 

You may FAX your Registration Form if paying 
by credit card. (To avoid duplicate billing, do 
not mail an additional copy.) 

Refund Policy 

If you must CANCEL, all refund requests must be 
in writing and postmarked no later than June 1, 
1992. 


NAME____ FIRST NAME FOR BADGE____ 

(flat) (last) 

COMPANY OR INSTITUTION_- 

MAIL ADDRESS -- 

CITY ___STATE_ZIP,_. COUNTRY_ 


TELEPHONE NO. (- 


NETWORK ADDRESS. 


(oneonly please) 


+ + + 

Tutorials 


Payment 


Fee Schedule 


Pre-registration is highly recommended. Regis¬ 
tration is first-come, first-served. Select only one 
full-day or two half-day tutorials per day. 

MONDAY, JUNE 8, 1992 
9:00 AM - 5:00 PM (INCLUDES BOX LUNCH) 

Ml □ Using NFS 

M2 □ Network Security (Kerberos) 

M3 □ The Internet & its Protocols 
M4 □ Sys VR4 Internals, Part 1 
MS □ OSF/1 Internals 
M6 □ Advanced Sys Ad Topics, 1992 
M7 □ Trusted Products & Systems 
M8 □ The Shell as Application Development 
Language 

M9 □ Introduction to Threads & Threads- 
Programming 

2nd choice, if first is filled_ 

TUESDAY, JUNE 9, 1992 
9:00 AM - 5:00 PM (INCLUDES BOX LUNCH) 

77 □ Distrib File System with AFS & DCE DFS 

T2 □ Topics in UNIX System Security 

T3 □ UNIX Network Programming 

T4 □ Sys VR4 Internals, Part 2 

TS □ X Window System: Xlib & Xt 

T6 □ Perl Programming Essentials 

T7 □ An Introduction to C++ 

T8 □ 4.4BSD Kernel Internals 
T9 □ 9 am - 12:30 pm (box lunch at 12:30) 
Preparing for Disaster 

T10 □ 1:30 pm - 5 pm (box lunch at 12:30) 
Domain Name System Mgmt. 

2nd choice, if first is filled___ 


• Payments MUST accompany Registration 
Form. 

• Purchase orders and vouchers CANNOT BE 
accepted. 

□ PAYMENT ENCLOSED (U.S. Dollars). 

Make check payable to: 

USENIX CONFERENCE. 

□ CHARGE TO MY: 

□ VISA 

□ MasterCard 

□ American Express 



Account No. 


- / - 

Expiration Date; Month/Year 


Cardholder's Signature 

Print Name 

*If you wish to join the USENIX 
Association check here: □ 

$65 of your non-member technical sessions 
fee will be applied as dues in full for one-year 
individual membership in the USENIX Asso¬ 
ciation. 


TUTORIAL FEES 

Two full-day or one $445 $_ 

full-day & two half-day tutorials 

One full-day tutorial 

or two half-day tutorials $245 $ . 

One half-day tutorial $150 $_ 

Late fee applies if postmarked 

after May 18, 1992. Add $50 $_ 

Full-time students 

Code No.: _. $__- 

Code No ,.\-$-.. 

TECHNICAL SESSIONS FEES 

Current member fee $255 $_ 

Applies to current individual members of 
the USENIX Association, Sun User Group, 

EurOpen or A UUG. If you are NOT a USENIX 
member and wish to join, pay the non-member 
fee and check the box below left. * 

Non-member fee* $320 $_ 

Late fee applies if postmarked 

after May 18,1992. Add $50 $ _ 

Full-time student fee - see reverse 
Pre-registered or on-site $75 $_ 

Students: attach photocopy of current 
student I.D. card to your registration form . 

TOTAL DUE: $ _ 
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Preliminary Announcement and Call for Papers 
The Third USENIX UNIX Security Symposium 
Baltimore, MD 
September, 14-17 1992 

In cooperation with 

The Computer Emergency Response Team (CERT) 


The goal of this symposium is to bring to¬ 
gether security practitioners, system administra¬ 
tors and system programmers, and anyone with an 
interest in computer security as it relates to net¬ 
works and the UNIX operating system. The sym¬ 
posium will consist of tutorials, invited speakers, 
technical presentations, and panel sessions. 

This will be a three-day, single-track sympo¬ 
sium. The first day will be devoted to tutorial 
presentations. The following two days will include 
technical presentations and panel sessions. There 
will also be two evenings available for birds-of- 
a-feather sessions and work-in-progress sessions. 

Papers are being solicited in areas including 
but not limited to: 

• User/system authentication 

• File system security 

• Network security 

• Security and system management 

• Security-enhanced versions of the UNIX op¬ 
erating system 

• Security tools 

• Network intrusions (including case studies 
and intrusion detection efforts) 

Important Dates 

Extended abstracts due May 

Notification to authors: June 

Camera-ready papers due July 


15, 1992 
15, 1992 
31, 1992 


Send seven copies of each submission to the 
program chair: 

Edward DeHart 

Computer Emergency Response Team 
Software Engineering Institute 
Carnegie Mellon University 
Pittsburgh, PA 15213-3890 
(412) 268-6179 
ecd@cert. sei. emu. edu 

Program Committee 

Ed DeHart (Program Chair) 

Computer Emergency Response Team 

Matt Bishop 
Dartmouth College 

Bill Cheswick 
Bell Laboratories 

Ana Maria De ANare 
Silicon Graphics, Inc. 

Jim Ellis 

Computer Emergency Response Team 
Barbara Fraser 

Computer Emergency Response Team 
Ken van Wyk 

Computer Emergency Response Team 


March/April 1992 
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Call for Participation: 1992 International Workshop 
on Object-Orientation in Operating Systems (I-WOOOS ’92) 
Dourdan, France, September 24-25, 1992 

Sponsored by Institut National de Recherche en Informatique et Automatique. INRIA and the IEEE Technical 
Committee on Operating Systems and Application Environments (TCOS) (pending) 


Introduction: 

In recent years the object-oriented approach 
to operating systems design, development, and 
application support has received growing interest. 
In 1989, about sixty researchers gathered together 
in Ottawa (Canada) to create a forum for research 
and discussion called I-WOOOS. This meeting 
was very successful and has become an annual 
event. I-WOOOS ’92 will be the third such work¬ 
shop. Last year’s workshop was held at Xerox 
PARC (USA) and had record attendance. To 
reflect the growing international interest in this 
area, the workshop will be held in France this 
year. The workshop has already earned a repu¬ 
tation for high quality combined with an informal 
format and strives to foster an atmosphere in 
which ideas can be presented and discussed at 
length. 


Subjects of Interest: 

Position papers are requested on all topics 
related to the title of the workshop (object- 
orientation and operating systems). 

The theme of the European workshop will be 
“Operating Systems Support for Distributed and 
Persistent Objects.” Full papers are requested on 
all topics related to the workshop theme. 

Additional subjects of interest include, but 
are not limited to: 

• Decomposition of an operating system into 
objects. 

• Object-oriented approaches to structuring 
an operating system. 

* Operating system support for object- 
oriented applications. 

* Hardware support for objects. 

• Operating systems, distributed systems and 
garbage collection. 

* Objects and distribution 


Workshop Structure: 

The workshop is structured so that existing 
established work can be presented alongside ini¬ 
tial exploratory work. As such, we invite papers 
for one of two categories: 

• Position papers: maximum 2000 words (ap¬ 
proximately 4 pages), which present initial 
work or new ideas, on any topic related to 
Object-Orientation and Operating Sys¬ 
tems. 

■ Full papers: maximum 6000 words (approx¬ 
imately 12 pages), which are technical in 
nature, describing actual results (of either 
established or experimental work) of wide 
interest, on the specific theme of the work¬ 
shop. 

Each attendee will be required to make a 
submission. Depending on the number of sub¬ 
missions, and due to the limited time allotted for 
the workshop, the committee will group the pa¬ 
pers into relevant categories and select a few rep¬ 
resentative submissions for presentation to set the 
tone for following discussions. 

Attendee Information: 

The official language for the conference will 
be English. Persons interested in this workshop 
are invited to send an electronic copy of either 
position or full paper, by May 8, 1992, to either 
the workshop general chairman or the program 
committee chairman listed below. Authors with¬ 
out access to the Internet may send TWO paper 
copies to the program or general chairman by the 
same date. 

Paper Format: 

Electronic submission is strongly encour¬ 
aged. Further information regarding submission 
format and a copy of this call for papers can be 
obtained via anonymous FTP: 
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address: ftp. diku. dk 

file: IWOOOS92/HOWTOSUBMIT 

file: IWOOOS92/CFP 

address: choices. cs. uiuc. edu 

file: IWOOOS92/HOWTOSUBMIT 

file: IWOOOS92/CFP 

Conference Proceedings: 

We will be publishing a pre-proceedings that 
will be available to attendees before the work¬ 
shop. Like last year, we plan to have IEEE pub¬ 
lish the proceedings. Authors must expect to sign 
IEEE copyright release forms. 

Workshop Location: 

The workshop will be held at Dourdan, just 
outside Paris, (France) and follows the 1992 Eu¬ 
ropean SIGOPS conference held at the Mont St. 
Michel in France. 

Additional Information: 

Roy Campbell, Workshop Chairman 

U. of Illinois, Dept, of Computer Science 

2413 Digital Computer Lab 

1304 W. Springfield Ave 

Urbana IL 61801 USA 

roy@cs.uiuc.edu 

Eric Jul, Program Committee Chairman 
Department of Computer Science 
U. of Copenhagen 
Universitetsparken 1 
DK-2100 Copenhagen, Denmark 
eric@diku.dk 

Local arrangements: 

Marc Shapiro, INRIA (France) 

Finance: 

Vince Russo, Purdue University, USA 


Publicity: 

Rodger Lea, Chorus systems (USA/France) 
Proceedings: 

Luis-Felipe Cabrera, IBM Almaden (USA) 

General Information (USA): 

Anda Harney, Dept, of Computer Science, 
2413 Digital Computer Lab, 

U. of Illinois, 1304 W. Springfield Av. 
Urbana, IL 61801 (USA), 
email: hamey@cs.uiuc.edu 
Tel 217-333-3328, Fax 217-333-3501 

General Information (DK): 

Karin Outzen, Dept, of Computer Science, 

U. of Copenhagen, Universitetsparken 1, 

DK-2100 Copenhagen 

e-mail: karino@diku.dk 

Tel +45 31 39 64 66, fax +45 31 39 02 21 

Program Committee 

Luis-Felipe Cabrera, IBM San Jose (USA) 

Roy Campbell, University of Ilinois (USA) 

Eric Jul, University of Copenhagen (Denmark) 
Reinhold Kroeger, GMD (Germany) 

Rodger Lea, Chorus Systems (USA/France) 
Hank Levy, University of Washington (USA) 
Jose Marques, INESC. (Portugal) 

Larry Peterson, University of Arizona (USA) 
John Rosenberg, University of Sydney (Austra¬ 
lia) 

Vince Russo, Purdue University (USA) 

Marc Shapiro, INRIA (France) 

Mario Tokoro, Keio Univ. and Sony Computer 
Science Lab. (Japan) 

Important Dates: 

Papers due: May 8, 1992 

Notification of acceptance: June 15, 1992 

Camera ready copies: July 17, 1992 

Workshop: September 24-25, 1992 
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Call for Papers: USENIX Systems Administration 
Conference (USA VI) 

Long Beach, CA October 19-23, 1992 
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The annual LISA conference provides a fo¬ 
rum in which system administrators from a variety 
of sites can meet to share new ideas and experi¬ 
ences. A growing success for the past five years, 
LISA is the only conference which focuses spe¬ 
cifically on the needs of system administrators. In 
previous years, LISA has targeted large installa¬ 
tions. However, this year we are extending the 
scope of LISA to include system administrators 
from all UNIX sites. 

The Sixth usenix System Administration 
Conference (LISA VI) will be held in Long 
Beach, CA on October 19-23,1992. A dual-track 
tutorial program will be offered during the first 
two days of the conference, followed by a three- 
day technical conference. The tutorial program 
will address issues in introductory and advanced 
system administration. 

The program committee will be reviewing 
papers submitted on subjects including (but not 
limited to): 

Tools for Real-Time System Troubleshooting 
Remote/Off-site System Administration 
Tricks in User Education 
Graphical User Interfaces for System Ad¬ 
ministration 

Distributed System Administration 
Experiences Using Third-party Administra¬ 
tion Software 

Network Growth and Performance Manage¬ 
ment 

How to Grow Your Own Junior System Ad¬ 
ministrators 
Network Management 
Wireless LANs 
System Security Monitoring 
Evaluating Performance of High-End Work¬ 
stations and Servers 
Keys to Successful, Painless Upgrades 
Object Management Systems for System Ad¬ 
ministration 

Standardization of System Administration 
Heterogeneous System Administration 
System Archiving and Backups 


We are especially interested in papers which 
provide freely available or fully described solu¬ 
tions to existing problems. We are also looking for 
papers which, in some way, advance the state of 
the art. 

The committee requires that an extended ab¬ 
stract be submitted for the paper selection process 
(full-papers are not acceptable for this stage; if 
you send a full paper, you must also include an 
extended abstract for evaluation). Your extended 
abstract should consist of a traditional abstract 
which summarizes the content/ideas of the entire 
paper, followed by a skeletal outline of the full 
paper. Final papers should be from 5 to 20 pages 
in length, including diagrams and figures. Papers 
should include a brief description of the site, an 
outline of the problem and issues, and a descrip¬ 
tion of the solution. We require electronic form 
of the extended abstract; we require both hard¬ 
copy and electronic (nroff/troff or ASCII) form of 
the final paper. 

Conference proceedings will be distributed to 
all the attendees and also will be available after 
the conference from the usenix Association. 

In addition to tutorials and regular technical 
sessions, a handful of other events will be in¬ 
cluded as part of the program. For example, the 
program may include special panels, work-in- 
progress reports, birds-of-a-feather (BOF) ses¬ 
sions, and invited talks. The program committee 
invites you to submit informal proposals, ideas, or 
suggestions you might have on any of these topics. 

Important Dates 

Extended Abstract Deadline: June 29, 1992 

Acceptance Notification: July 20, 1992 

Final Papers Received: August 31, 1992 

Contact Information 

Submit electronic copy of extended abstracts 
to: 
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Trent Hein 

XOR Computer Systems 
2525 Arapahoe, Suite E4-264 
Boulder, Colorado 80302 
(303) 440-6093 
trent@xor.com 


Program Committee 

Trent Hein XOR Computer Systems 

(program chair) 


Rik Farrow 
Jeff Forys 
John Hardt 
Herb Morreale 
Pat Parseghian 
Jeff Polk 


UNIX World 
University of Utah 
Martin Marietta Astronautics 
XOR Computer Systems 
AT&T Bell Laboratories 
Sun Microsystems 


Prime Time Freeware CD 


usenix has arranged a special discount for 
USENIX members for the first issue of Prime 
Time Freeware. This CD contains over 1,500 
MB of UNIX-related source code. The disc con¬ 
tains compressed tar files in the ISO-9660 CD- 
ROM format. A 50 page booklet introduces 
and explains the disc. Over 100 packages com¬ 
prise Volume 1 Number 1, including: 

• Andrew windowing code 

• Athena (except Kerberos) 

•CLU 

• comp.sources.{3bl,amiga,sun,ga 
me-s,unix,x} 

• Epoch 

• GNU (current and vintage versions) 

• Icon 

• Interviews 

• ISODE 

• Kermit (tapes A-E) 

• Mach 

• NCSA Data Analysis Code 


• Scheme 

• Serpent 

*T 

• Utah Rendering Toolkit 

• X11R5 

Order the disc and booklet directly from: 

Prime Time Freeware 

415-112 N. Mary Ave., Suite 50 

Sunnyvale, CA 94086 USA 

+ 1 408 738-4832 

cfcl!ptf@apple . com 

The discounted price for usenix members 
is $50, a savings of $10 per disk (quantity 1-9), 
plus domestic shipping of $5/order ($10/order 
for foreign shipping). California residents 
should add 7% sales tax. 

Contact Prime Time Freeware for details 
on larger orders or for other arrangements. 
Orders may be paid by check, money order, or 
wire transfer. 
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Calendar of UNIX-Related Events + 


1992 Apr 27-28 
1992 May 4-8 
1992 May 18-22 
1992 May 20 
1992 May 21-22 
Summer 
1992 Jun 2-4 
1992 Jun 8-12 
1992 Jun 21-24 
1992 Jul 7-9 
1992 Jul 13-17 
1992 Aug 10-13 
1992 Sept 8-11 
1992 Sept 14-17 
1992 Sept 22-24 
1992 Sept 22-24 
1992 Oct 6 
1992 Oct 19-23 
1992 Oct 19-23 
1992 Oct 26-30 
1992 Nov 25-27 
1992 Dec 


*Micro-Kemel Workshop 
DECUS 

ISO/IEC JTC1 SC22 WG15 
Sun UKUG 
*File Systems 
UKUUG 

UNIX EXPO West 
*USENIX 
Sun User Group 
JUS 

IEEE 1003 
*C++ 

AUUG 
*Security III 
UNIX Expo 
SUKUG 

ISO/IEC JTC1 SC22 WG15 
*LISA VI Conference 
IEEE 1003 
Interop 

EurOpen/UniForum 

UKUUG 


1993 Jan 11-15 
1993 Jan 25-29 
1993 Mar 15-18 
1993 Mar 24-31 
1993 Apr 5-19 
1993 Apr 26-30 
1993 Jun 21-25 
1993 Jul 12-16 
1993 Oct 18-22 
1993 Oct 25-29 
1993 Autumn 


IEEE 1003 
*USENIX 
UniForum 
CeBIT 93 
IEEE 1003 
EurOpen 
*USENIX 
IEEE 1003 

ISO/IEC JTC1 SC22 WG15 
Interop 

EurOpen/UniForum 


1994 Jan 17-21 
1994 Feb 14-17 
1994 Mar 16-23 
1994 Mar 23-25 
1994 Apr 18-22 
1994 Jun 6-10 
1994 Sept 12-16 
1994 Autumn 


*USENIX 
Uniform 
CeBIT 94 
UniForum 
EurOpen 
*USENIX 
Interop 

EurOpen/UniForum 


Seattle, WA 
Atlanta, GA 

UK 

Ann Arbor, MI 
Belfast, Northern Ireland 
Anaheim, CA 
San Antonio, TX 
Washington, DC 
Tokyo, Japan 
Chicago, IL 
Portland, OR 
Melbourne, Australia 
Baltimore, MD 
New York, New York 
Birmingham, UK 
Denmark 
Long Beach, CA 
Utrecht, The Netherlands 
San Francisco, CA 
Utrecht, The Netherlands 
Manchester, UK 


San Diego, CA 
San Francisco, CA 
Hannover, Germany 

Spain (tentative) 
Cincinnati, OH 

Atlanta, GA 

San Francisco, CA 

Utrecht, The Netherlands 

San Francisco, CA 
Dallas, TX 
Hannover, Germany 
San Francisco, CA 

Boston, MA 

San Francisco, CA 

Utrecht, The Netherlands 


1995 Jan 16-20 *USENIX 

1995 Feb 21-23 Uniforum 

1995 May 1-5 EurOpen 

1995 Jun 19-23 *USENIX 


New Orleans, LA 
Dallas, TX 

San Francisco, CA 


1996 Jan 22-26 *USENIX 

1996 Mar 12-14 Uniforum 

1996 June 17-21 *USENIX 


San Diego, CA 
San Francisco, CA 
Washington, DC 


+ Compiled with the assistance of Alain Williams of EurOpen. 
*USENIX conferences, workshops, and symposia. 
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San Francisco ’92 Conference Wrap-Up 

Eric AUman , Program Chair 

I’d like to take the opportunity to thank every¬ 
one who helped make the San Francisco usenix 
conference a success. Such a list is too long to list 
here (especially given all the other items I want 
to cover). However, like a theater production, 
there were probably at least two people backstage 
for everyone you saw on stage. 

Best Student Paper Awards 

The USENIX Board of Directors has autho¬ 
rized a cash award for Best Paper and for Best 
Student Paper. In this case, we believed that the 
best papers were both written by students; for this 
reason, the program committee awarded two Best 
Student Paper awards without distinguishing be¬ 
tween them. 

The winners were “A Trace-Driven Analysis 
of Name and Attribute Caching in a Distributed 
System” by Ken Shirriff and John Ousterhout 
(University of California, Berkeley) and “agrep 
- A Fast Approximate Pattern-Matching Tool” 
by Sun Wu and Udi Manber (University of Ar¬ 
izona, Tuscon). 

Runners up were “NFS Tracing by Passive 
Network Monitoring” by Matt Blaze (Princeton) 
and “LIBTP: Portable, Modular Transactions for 
UNIX” by Margo Seltzer and Michael Olson (Uni¬ 
versity of California, Berkeley). 

The Keynote 

Mitch Kapor, President and CEO of the 
Electronic Frontier Foundation, delivered the 

Management of Large-Scale Distributed Prototypes 
for an 

8-bit-clean RISC PC-compatible POSIX-compliant 
UNIX-based CASE 
Environment Architecture 
for 

Artificially Intelligent Caching 
of 

Client Customizable Desktop Databases 
Distributed Among 

Dynamic Efficient Encrypted Event-Driven Expert Systems 

that is 

Extensible Fast and Fault-Tolerant 


Keynote Address on Wednesday morning. His 
talk discussed the emerging public data network 
that is not unlike the public telephone network. 
The EFF is dedicated to educating the public and 
policy makers about computer-based communi¬ 
cations media and information networks. 

For general information regarding the Elec¬ 
tronic Freedom Foundation, send email to 
eff@eff.org. A newsletter is published on the 
newsgroup comp.org.eff.news, or can be sub¬ 
scribed to by sending email to eff-news- 
request@eff.org. 

A special mailing list devoted to public net¬ 
work infrastructure can be subscribed to by send¬ 
ing email to pub-infra-request@eff.org. 

Personal correspondence can be directed to 
Mitch Kapor at mkapor@eff.org. 

The Rogue Talk 

Much to the surprise of all of us, another talk 
appeared on the program: “Managing Large Dis¬ 
tributed Systems” by Win Treese was scheduled 
into the Thursday 8:30-10:00 AM session (at 
least according to the information booklet). 

Despite the fact that Win hadn’t been in¬ 
formed that he was giving a talk, he managed to 
deliver it anyway. Since his paper was received 
too late to be included in the proceedings, it is 
printed here in its entirety: 
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based on 

Fiber Optic Global Graphical User Interfaces 
for 

Heterogeneous Hierarchical High Throughput 

High-Temperature Superconducting Networks 
in an 

Integrated Highly Available Inexpensive Internationalized 
Interoperable Interpreter 
for 

Knowledge-Based Journaling of Load-Balancing Log-Based Networks 

with 

Modular Low-Latency Massively Parallel Multimedia 
Natural Language Neural Networks 
in an 

Open Pipelined Object-Oriented Framework 
for 

Portable Protocol-Independent Reliable Real-Time Process Migration 

with a 

Secure Shared Multi-Level Scaleable Self-Organizing Replicated Repository 

based on 

Simple Standard Superscalar Software Engineering Technology 

with a 

Trace-Driven Transactional Ubiquitously User-Friendly Toolkit 

for 

Vectorized Vendor-Neutral Virtual User Interfaces 

on 

Multi-Threaded RPC Servers 

Don’t even think about it. 


Thank you Win. 

The Contest 

The conference contest, “Name That File 
System”, was a great success, with several hun¬ 
dred (yes, you read that right) entries. The rules 
read as follows: 

In the beginning, there was the file system, 
and it was good enough for the disk technology 
of the time. Then disks got bigger, and the block 
size was expanded from 512 bytes to IK, and the 
1KFS was bom. 

But this was not Good Enough, and so the 
Fast File System (FFS) had to be. And it came, 
and 1KFS went. 

Then the Sun rose in the west, and there were 
networks, and NFS (Network File System) came 
to pass. But the east wanted to get in on the deal, 
and so there was RFS (Remote File System) too. 

But there also had to be a local file system, 


and so the file system switch was born of virgin 
parents. And that was the end of self control. 

Now we have LFS (Log Structured File Sys¬ 
tem), TFS (Translucent File System), MFS 
(Memory-based File System—the file system that 
has files and is a system, but isn’t a file system), 
and being introduced at this conference, the 3DFS 
(Three-Dimensional File System). Not to mention 
a few others (which I won’t mention). 

What’s next? Surely we can think of some¬ 
thing! Like: 

• SFS—Stochastic File System. When you 
open a file, it opens a file at random. Opens 
go very quickly, and it is useful for selecting 
random input to programs. (Not I couldn’t 
use the name RFS [Random File System] 
here, because the initials were taken). 

• MMFS—Mickey Mouse File System. Runs 
in your watch. 

• LIFS—Language Independent File System. 
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You have to do a set_locale() call before 
you open the file; all text files are translated 
into the appropriate language on reads and 
writes. 

• SSFS—Slow SLIP File System. Carefully 
tuned to give performance commensurate 
with Serial Line IP over a 1200 baud mo¬ 
dem. (Also, note the rare triply nested ac¬ 
ronym [S [ = Slow] S [ = S [= Serial] L 
[ = Line] IP [= Internet Protocol]] F 
[ = File] S[ = System]].) 

• SMFS—Sendmail File System. I don’t know 
what this does, but I had to propose it now 
to avoid the obvious submissions. In any 
case, the semantics are certainly defined by 
rewriting rules. 

The rules of the contest are simple: 

(1) All submissions must have an “Y.YFS” 
style name and a one-line expansion of 
the initials. 

(2) There must be a (short) semantic descrip¬ 
tion of the file system. Short and snappy 
is better than full descriptions (after all, 
we can always read the man page). 

(3) All submissions must have your name and 
email address. Teams are OK, but pick 
one person to act as a representative. 

(4) Submissions are due by 5:00 PM on 
Thursday. Boxes will be set up in the 
registration area. 

(5) We’ll try to publish all submissions in 
;login: and in comp.org.usenix, so try to 
make your submissions printable. 

(6) Winners will be announced at 3:20 PM 
Friday (immediately before the last ses¬ 
sion). 

(7) Decisions of the (guaranteed biased, ar¬ 
bitrary, etc.) judges are final. 

(8) Prizes cannot be returned. 

(9) There may be other arbitrary rules added 
as we think them up. 

We ignored some of our own rules (as spe¬ 
cifically permitted; we made rules that unmade 
rules), as will be clear in the winning entries. 

The biased panel of judges apologizes if it 
missed some especially good ones; when you read 
that many, your definition of what is funny seems 
to get a bit blurry. 

We had to reject some otherwise excellent 


entries on technical grounds. For example, the 
following entry by Bill Roome 
<wdr@research.att.com> had already been im¬ 
plemented: 

ZFS—Zork File System (also known as the 
Adventure File System, but AFS has been taken): 
provides a Zork-like interface. It’s best illustrated 
by example: 

$ cd src 

You are in a large, dark directory. Something 
smells very bad here. 

$ Is 

There are lots of small files here, too many 
to list. 

$ cat x.c 

You can’t; your screen is full. Throw some 
characters away and try again. 

$ cd bar 

You can’t go in that direction. [The judges 
thought this should read “You are in a maze of 
twisty symbolic links, all alike.”] 

$ c d • • 

Your way is blocked by a large, hungry lisp 
interpreter. It takes all your pages. Oh my, you 
are dead! Shall I try to reincarnate you? 

Several deeply philosophical submissions 
were received: 

ZENFS—What is the sound of one head 
crashing? (Annadiana Beaver, Rick Auricchio, 
Adam Moskowitz, Andy Tannenbaum [the other 
one!]. Bill Stewart, and Mike Weaver). 

ZFS—Zen File System: Extremely storage- 
efficient—file contents are encapsulated in koans. 
Users often achieve enlightenment, and no longer 
need to type ‘ps’ to figure out what’s going on 
(Mike Olson <mao@CS.Berkeley.EDU>). 

EXFS—Existential File System: Analyzes 
the cosmic significance of all data. Reads return 
random data, for there is no difference, cosmi- 
cally speaking, between one collection of bits and 
any other. Writes may unexpectedly fail with the 
ermo EDESPAIR, if the write code failed to 
believe that the data passed would make any 
change, cosmically speaking [do writes ever suc¬ 
ceed? -ed]. 
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SIS YFS (pronounced ‘ ‘Sisyphus ”)—j ust 
when you think you’ve mounted a partition, it 
unmounts itself (Margarita Suarez 
<marg@Columbia.EDU>). 

There were several versions of PCFS (Polit¬ 
ically Correct File System), half a dozen BOFS 
(Birds of a File System), and several SFFSs (San 
Francisco File System, usually referring to the 
‘diverse culture’ available in San Francisco). We 
had to reject all of these on the grounds that they 
must have been too obvious (?). 

There were a number of special awards. 

The Tongue Twister award went to Tomas 
Andersson <tomas@mvsun.ericsson.se> for the 
pair of entries: 

FSFFS—Free Software Foundation File Sys¬ 
tem: puts a copyleft on every file. 

FSFFFS—FSF Free File System: no copyleft 
here. 

The judges then amused themselves by com¬ 
ing up with a grammar: 

acr: acr_head acr_tail; 

acr_head: “FSF”; 

acr_tail: “FS” | “F” acr_tail? 

Tom Christiansen <tchrist@Convex.COM> 
won the “Are We Still Friends?” award for 
PERLFS—Pathologically and Exceedingly Re¬ 
pulsive Lwall-ian File System: Emulates all other 
known and imagined file systems using super- 
overloaded system calls that take line noise for 
arguments. Contains extra syscalls just for reading 
news, and automatically applies patches to itself 
upon encountering them in any newsgroup. Cur¬ 
rent patch level is 2,367. (Larry Wall was re¬ 
splendency attired in a rather brightly colored 
tuxedo during this presentation.) 

The “Aren’t we taking this a bit too seri¬ 
ously?” award went to Bruce Haddon 
<Bruce_Haddon@stortek.com> for FFFS— 
Fast Fourier File System: Time (program execu¬ 
tion) domain file requests are transformed into 


the frequency domain, such that repetitive ac¬ 
cesses are performed only every 2 n th time. Per¬ 
formance improves exponentially with load. 

An Honorable Mention went to Ron Heiby 
<heiby@chg.mcd.mot.com> for MFS— Market¬ 
ing File System: provides the service of being able 
to stat files that may or may not exist at some 
point in the future. The date fields are always set 
to the end of the current fiscal quarter. 

The Children’s Award goes to Bill Cheswick 
for SMURFS—A small pudgy file system that 
only works on Saturday morning. Only your three 
year old can use it. 

Jef Poskanzer <jef@well.sf.ca.us> walked 
away with the Sports Award for SFFS—Soccer 
Fan File System: Rent one of those really huge 
soccer stadiums in South America, fill it with a 
million fans carrying flash cards with “1” and “0” 
on them. If they do “the wave”, you lose your 
data. 

The Grand Moose Award went to David Paul 
Zimmerman <dpz@dimacs.Rutgers.EDU> for 
BFS—Bullwinkle File System. Special thanks go 
to Dan Klein and Tom Christiansen for providing 
the sound effects: “Hey Rocky, watch me pull a 
file out of my hat!” (“Ah, that trick never 
works.”) “This time for sure!” 

The Certain Award goes to Margo Seltzer 
<margo@CS.Berkeley.EDU> for HUFS 
—Heisenberg Uncertain File System: You can 
know where your file is or what’s in it, but not 
both. 

John Kohl <jtkohl@CS.Berkeley.EDU> 
won the Yo-Yo Award for (what else?) YYFS— 
the Yo-Yo File System: It goes up and down and 
up and down, and doesn’t get any work done. 
(His prize was, naturally, a usenix Yo-Yo.) 

A special award went to the following entry 
for being the only submission that actually com¬ 
piles, printed here in its entirety: 


/* 

* Copyright (c) ms The Regents of the Restaurant of Le Central. 

* All rights deserved. 

* 

* Fly-Fishing Filesystem (FFFS) public definitions. 

# 

* This source code is derived from a restaurant tablecloth scribbled on 
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* by Eric Brunner, Marc Donner, Jan-Slmon Penary and Bucky Pope. 

* 

* Redistribution and use In cooked and raw foras, with or without garlic, 

* are pernittea provided that the following conditions are met: 

* 1. Redistributions of fish must retain the above copyright 

* notice, this list of conditions ana the following disclaimer. 

* 2. Redistributions in cooked form must reproduce the above copyright 

* notice, this list of conditions and the following disclaimer in the 

* menu ana/or other materials provided with the food. 

* 3. ill advertising materials mentioning features or use of this fish 

* must display the following acknowledgement: 

* This food includes fish caught with the Ply-Pishing Filesystem 

* developed at the Restaurant of Le Central by its ainers. 

*4. Neither the name of the Restaurant nor the names of its diners 

* may be used to endorse or promote fast food products derived from 

* this fish without specific prior written permission. 

* 

* 1.2 (Le Central) 1/22/12 
*/ 

ifndef_FFFS_H 
define _FFFS_H 
/* 

* NB: Requires the new liven, aeaa« and freshii type 

* modifiers in ANSI C. 

*/ 

include fffs/license.h /* for fishing license ana legal size */ 
include fffs/utensils.h /* for type pan */ 
include fffs/tackle.h /* for struct lure ana struct line */ 
define LEGAL_SIZE(fish) (slzeof(fish) T00_SMALL) 

/* to kill the fish, just cast it to aeadn */ 
define KILL(fish) ((dead) (fish)) 
struct fish; 
struct bite; 

typedef struct bite meallO; 

/* 

* VFS (victual file system) operations for FFFS. 

V 

/* 

* cast() takes a lure, casts it ana returns a pointer to the fishing line. 

* on error it returns null and sets errno to one of: 

* 

* ECALIFORNIA - No water. 

*/ 

struct line *cast(const struct lure *fly); 

/* 

* hook() takes a pointer to a fishing line and returns 

* a fish descriptor (fd). 

*/ 

lnt hook(const struct line *1); 

/* 

* reel() takes a fish descriptor ana returns a pointer to a fish. 

* reel() closes the fish descriptor (fa). 

* on error it returns null and sets errno to one of: 
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* 

* EB&DF - Baa Pish. 

* ECONNABORTED - It got away. 

* ENETDNREACH - Fishing net unreachable. 

* ETOOBIG - The one that got away. 

V 

live struct fish *reel(int fd); 

/* 

* unhook() removes the fish from the hook, returning the fresh fish 
*/ 

live struct fish unhook(live struct fish *catch); 

/* 

* releaseO returns the live fish to the free pool. 

V 

void release(live struct fish f); 

/* 

* fry() takes a fish, and a pan and makes a meal. 

* on error it returns null and sets errno to one of: 

* 


* EBONES - Fish couldn't be filleted. 

* EINEDIBLE - Fish caught off Long Island. 

* ENOSPC - Frying pan full. 

* ESTALE - Fish not fresh. 

* ETOOSHALL - Fish is illegally small. 

*/ 

fresh meal *fry(dead struct fish f, pan p); 
endif /* _ FFFS_ H */ 


Third Prize goes to Gordon C. Galligher 
<gorpong@sbcoc.COM> for MJFS—Michael 
Jackson File System: This file system spends 90% 
of its time updating itself. 

Second Prize to Win Treese 
<treese@crl.dec.com>: SFS—Sashimi File Sys¬ 
tem: Only works on the raw device. (We had 
another entry for a Sushi File System, but con¬ 


cluded that it was implemented as a symbolic link 
to the Sashimi File System). 

Finally, First Prize. This is a bit embarrass¬ 
ing: of the hundreds of scraps of paper I carried 
home with me, this entry was the one I lost, so 
I have to reconstruct it. As I recall, the award goes 
to Simon Spero for GBFS—George Bush File 
System: as seen on the best Japanese laptops. 
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Works-In-Progress Summaries from Winter ’92 Conference 

Lisa Bloch 


[Editor’s Note: Lisa Bloch coordinated the 
Works-in-Progress (WIPs) session at the Winter 
’92 usenix conference in San Francisco. She has 
submitted these summaries of the work presented 
there.] 


NFS as a User Interface to a High Perfor¬ 
mance Data System 

Christina Mercier, Los Alamos National Lab¬ 
oratory 

NFS will be the user interface to a High 
Performance Data System (HPDS) under devel¬ 
opment at Los Alamos National Laboratory 
(LANL). HPDS will manage high-capacity, high- 
performance storage systems connected directly 
to a HIPPI (High Performance Parallel Interface) 
network. The HPDS software will be distributed 
in workstations. NFS will be modified to maxi¬ 
mize performance and manage massive amounts 
of data. LANL is in the middle of the design phase 
of HPDS and has successfully demonstrated some 
design concepts through a prototype. 


A Distributed Bibliographic Database System 

Richard Golding, UC Santa Cruz 

The Refdbms system provides distributed da¬ 
tabases of bibliographic information. Copies of 
the database are replicated at several hosts, typ¬ 
ically one per organization. The system allows 
users to search large databases of references, en¬ 
ter new references, obtain copies of papers (when 
on-line versions exist), and use the references in 
TeX and FrameMaker documents. They can also 
create new databases, and import or export da¬ 
tabases to and from other Internet hosts. 

The system uses epidemic replication tech¬ 
niques to keep databases consistent. It is in part 
an experiment in the performance of weak- 
consistency replication protocols on the Internet. 

The system will be made available to the 
Internet in February 1992. I will give a brief in¬ 
troduction to the system, discuss how it compares 


to other bibliographic database systems, and dis¬ 
cuss the new epidemic protocols being tested. 

A Programming-Language Shell 

Per Bothner, Cygnus 

Modern high-level programming languages 
provide multiple data types (such as numbers, 
strings, and lists), as well as first-class function 
values. Most utility languages (awk, peri, tel) and 
most shells only have one (or a few) data types 
(strings), but they are very convenient for ma¬ 
nipulating text or invoking programs. I will dis¬ 
cuss the issues involved in getting the best of both 
worlds, in the context of the free Q programming 
language. 

For example, executing a program has the 
same syntax as a function call, a pipe is function 
composition, and a disk file just a persistent 
string. The implications of these features on the 
syntax and structure of the programming language 
are discussed. 


Distributing /etc/fstab by Centralising It 

Boyd Roberts, Digital Equipment Corpora¬ 
tion <boyd@prl . dec . com> 

We have a a heterogeneous collection of net¬ 
worked machines whose file systems require shar¬ 
ing to provide a common file system namespace. 
The traditional /etc/fstab model does not provide 
sufficient flexibility, is difficult to maintain and 
does not provide a global view. Typical solutions 
involve distributing N versions of /etc/fstab or 
resorting to the automounter and Yellow Pages 
maps. Neither of these solutions are sufficient; the 
former is too basic, while the latter is too com¬ 
plex. We have implemented a simple model which 
is flexible because of its simplicity. 

We describe file systems in one ASCII text 
file which specifies the file system, its server and 
a list of client/mount-point/mount-option triples. 
This file is read by a server which uses a simple 
connection-based protocol. Client hostname spec¬ 
ification is done with ed(l) style regular expres¬ 
sions. Clients request which file-systems they 
should mount from a list of servers specified as 
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command line arguments. A separate server find¬ 
ing protocol has been explicitly avoided. 

The protocol has been designed so that the 
server can be interrogated by sh(l) scripts, and 
this allows great flexibility; a client’s /etc/fstab can 
easily be recreated with a sh(l) script. To repli¬ 
cate the configuration file on other servers the 
protocol supports a query which will return a 
server’s state in the format of the configuration 
file. This aids readability and tools such as diff(l) 
can be used to determine server configuration 
anomalies as well as bugs! 

Network Security System for Distributed Soft¬ 
ware Development Environment shared with 
Subcontractors 

Hideo Asami , Masashi Miyawaki, Kiyoshi 
Tanaka and Shunichi Fukuyama , NTT Soft¬ 
ware Laboratories, Japan 

Nippon Telegraph and Telephone Corpora¬ 
tion (NTT) has constructed a distributed software 
development environment (DSDE) using a na¬ 
tionwide TCP/IP network and UNIX worksta¬ 
tions for its internal use. 

NTT sometimes orders large scale software 
from subcontractors. Both parties share this en¬ 
vironment for cooperative development. Hence, 
information security is a critical issue. Informa¬ 
tion interchange between corporations, and in¬ 
formation security of corporations should be con¬ 
sistent with each other. That is, the following 
utility and security conditions are required: 

• NTT and subcontractor members can com¬ 
municate mutually, transfer files to each 
other, and share target machines. 

• NTT and subcontractor members never ac¬ 
cess the environment in which each other’s 
secret information is kept. 

To realize such consistency, we have estab¬ 
lished the following security control system: 

1. Partitioning the environment into three 
segments: 

• An NTT members’ network for the com¬ 
munity organized with only NTT members, 

• A cooperative network for the community 
organized with both NTT and subcontrac¬ 
tor members, 

• A subcontractor’s network for the commu¬ 


nity organized with only subcontractor 
members. 

2. Information flow control between these 
segments according to the protocol layers; 

• Network layer control, which intercepts IP 
routing between the NTT members’ net¬ 
work and the subcontractor’s network, but 
permits communication in the cooperative 
network. 

• Transport layer control, which intercepts 
accesses from the cooperative network to 
the NTT members’ network, but permits 
opposite accesses. 

• Application layer control, which intercepts 
electronic mail and news between the NTT 
members’ network and the cooperative net¬ 
work. 

We have applied this security control concept 
to our DSDE, which includes approximately 
3,000 nodes, and have confirmed its effectiveness 
and robustness. 

The RX Hex 

Dave Bachmann, Peter Honeyman, Larry 
Huston, CITI, The University of Michigan, 
Ann Arbor 

At CITI, we are interested in running data- 
less AFS clients over dialup IP networks. Im¬ 
proving RX performance is critical to that task. In 
this talk, we report on our progress in adapting 
RX to networks characterized by low bandwidth 
and high delay. Our focus is on adding facilities 
for congestion avoidance and control, and on 
compressing RX headers. Our work is ongoing. 
We have overcome several hurdles and are now 
getting impressive data transfer rates over ordi¬ 
nary dialup lines. 

Taking a Little Work Along 

Peter Honeyman, CITI, The University of 
Michigan, Ann Arbor 

The Little Work prototype is a notebook 
computer well-endowed with memory and local 
disk. It runs Mach and AFS, operating predom¬ 
inantly in a dataless mode. The network interface 
is the serial port, attached to a fixed or cellular 
phone, attached to a high-speed modem. 

To economize on limited network bandwidth 
and substantial cellular phone charges, AFS has 
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been engineered to support compressed headers 
and will be made to operate in a disconnected 
mode. Technical challenges abound, such as con¬ 
gestion avoidance and control for AFS, 
application-level support for network reconfigu¬ 
ration, dynamic IP address assignment, X win¬ 
dows over VGA, operating system support for 
battery power management, etc. 

The underlying thesis of the Little Work 
project is that mobile computers are capable of 
supporting the kind of distributed computing en¬ 
vironments common in academia and industry. 
The Little Work prototype makes a powerful 
statement in what is achievable today, and posi¬ 
tions CITI to take advantage of further enhance¬ 
ments in computing technology: faster notebook 
computers, better screens, denser memory and 
disks, digital cellular communications, etc. 

Plum, an Extensible MH Visual Front-End 

Tom Christiansen, Convex 

What is plum? Well, basically, it’s a mail 
reader, but that’s like saying that emacs is an 
editor or that UNIX a disk I/O system. It uses MH 
as its underlying interface, so people already used 
to MH will find it very easy to use. Think of it as 
a combination of the following programs: all the 
mh programs, vi, dired, m, tcsh, and of course 
perl. Like Stallman, I needed an extension lan¬ 
guage that was interpreted, one which would give 
me dynamic binding and scoping and autoloading. 
It should come as no surprise to anyone that I 
should have chosen perl for this purpose. 

I was deeply frustrated with xmh, had too 
many years invested in MH to use a simpler but 
less functional mailer like elm, and would be 
damned if I was going to jump into emacs and 
LISP merely to get at mh-e. I wanted something 
easy for my fingers to deal with, something that 
let me get through a lot of mail as quickly as I 
could, something that was faster than MH by 
itself, and something which was infinitely exten¬ 
sible. 

Dynamic Hierarchical Caching for Large- 
Scale Distributed File Systems 

Matt Blaze, Princeton University 

In a previous paper we conjectured that 
large-scale distributed file systems can benefit 
from organizing clients into cache hierarchies. In 


a cache hierarchy, only a few clients communicate 
directly with the file server. These clients serve 
requests from other clients, who in turn serve 
clients lower in the hierarchy, and so on. If a file 
is already in a lower level cache, the file server 
never sees the requests. In a paper in this con¬ 
ference, Muntz and Honeyman use data from 
DEC-SRC to show the surprising result that hi¬ 
erarchies are not always a good idea, introducing 
needless delay and only modest benefit. 

In this presentation, I outline a simple tech¬ 
nique for constructing dynamic client hierarchies 
on a file-by-file basis, and show some results of a 
trace driven simulation (using the same DEC- 
SRC trace data) that suggest a large reduction in 
server load with only limited client overhead for 
shared file access. 

Networking Tools (for 4BSD) 

Geoff Collyer, Software Tool & Die, Brook¬ 
line, MA, geoff@world.std.com 

4BSD UNIX provides support for TCP/IP 
and other network protocols over various media. 
Unfortunately, the system call interface is quite 
low level, dealing with, for example, IP addresses 
and ports, rather than host names and services. It 
is also awkward to program. It involves the use of 
arcane structures, and few standard subroutines 
exist to ease the programmer’s burden, so most 
network applications contain near-identical boil¬ 
erplate code to advertise services and initiate con¬ 
nections. The standard applications appear to 
have been intended for interactive use and are 
often difficult to adapt to non-interactive use (e.g. 
ftp). 

Mark Moraes and I wrote subroutine librar¬ 
ies and new applications that exploit existing pro¬ 
tocols and operating system support, yet are con¬ 
venient to program and use. We implemented the 
Research UNIX ipc(3) subroutines (as far as pos¬ 
sible on 4BSD) for TCP/IP. The underlying TCP 
support routines are a separate library, but are 
generally accessed through the ipc routines to 
simplify changes to use another transport. We 
have adapted some of our existing code to use ipc 
and found that it both decreased the source code 
size and generalized the programs’ capabilities, 
since ipc accepts either host names or ‘dotted 
quad’ IP addresses and service names or port 
numbers. We have also written new applications 
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using ipc in a style that permits convenient non¬ 
interactive use and often convenient interactive 
use. As a result, we can automate mirroring of ftp 
archives easily. We have a faster and smaller 
NNTP server than the standard one. 

We wrote a command, onpty , to run a com¬ 
mand on a pseudo-terminal, with optional utmp 
entry, to cope with the distressing array of pro¬ 
grams that expect to be run on (pseudo-) termi¬ 
nals. Onpty runs on most modem UNIXes. The 
use of onpty with rsh(l) (normally invoked via a 
wrapper script) permits remote execution of ar¬ 
bitrary commands, notably passwd(l) and video 
editors. This is sufficient to permit use of symbolic 
links rather than, for example, Sun’s NIS. 


We plan to provide a more convenient in¬ 
terface to the Domain Name System (DNS), a 
new nameserver, a new design for the DNS, net¬ 
work file system access to services such as ftp and 
pop, and a connection server. 

ANDF — Architecture Neutral Distribution 
Format 

Andy Johnson , Open Software Foundation 

Discussion on ANDF. The talk focused on 
the selected technology, including: 

• the current platforms supported, 

• the current performance data, 

• the application portability model, and 

• the current state of applications ported to 
ANDF. 


USENIX Board of Directors’ Meeting 


Below is a summary of the actions taken at 
the regular quarterly meeting of the usenix 
Board of Directors held at the Hilton Hotel in San 
Francisco, CA on January 19, 1992. 

Attendance: 

Rick Adams, Ed Gould, Rob Kolstad, Kirk 
McKusick, Sharon Murrel, Evi Nemeth, Mike 
O’Dell, Barry Shein, Ellie Young, Judy DesHar- 
nais, Dan Klein, Eric Allman, Nawaf Bitar, Tom 
Christiansen, Peter Collinson, Daniel Geer, 
Michel Gien, Lori Grob, Trent Hein, Steve 
Johnson, Sonya Neufer, Greg Rose, Stephe Walli 

Winter ’92 Conference. Allman reported that 
things had gone smoothly, and that the following 
worked well: having a scribe at the program com¬ 
mittee meeting; providing a template for authors 
to provide camera-ready papers for the proceed¬ 
ings; the WIPs were strong and had expanded to 
two sessions; and the interaction with the staff was 
good. DesHarnais reported that 1631 were pre¬ 
registered and a higher number than normal were 
attending tutorial sessions only as compared to 
other conferences. 

Klein reported that tutorial attendance was 
good with an estimated 2100 seats sold. A dis¬ 
cussion ensued regarding possible topics and 
speakers for future tutorial offerings, as well as 
the appropriate level/titles. 


Mach ’91 Symposium. Young reported that 
257 people attended (compared to 197 at the pre¬ 
vious year’s workshop). The tutorial and technical 
programs were very well-received, and Alan 
Langerman did an excellent job as program chair. 

SEDMS III and IV. O’Dell reported that 42 
submissions were received for the upcoming sym¬ 
posium, of which 19 were selected and the papers 
were strong. It was agreed to tentatively approve 
the proposal from Cohn and Reiher to sponsor a 
fourth symposium in 1993. 

Winter ’93 Conference. It was agreed to ac¬ 
cept Kolstad’s suggestion to conduct an experi¬ 
ment with this conference, where he would take 
on the role of conference convener, with Dan 
Geer chairing the program committee. 

Summer ’93 Conference. David Rosenthal 
agreed to serve as program chair. 

1996 Conferences. Lower room rates were 
secured at the San Diego Marriott Hotel for the 
Winter meeting, and the Washington, D.C. Hil¬ 
ton would be the site for the Summer. 

Journal Report. O’Dell reported that the 
production schedule was finally back on track, 
and that the first issue for 1992 (5:1) was in type¬ 
setting and would be shipped to our members in 
March. 
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;login:. Kolstad reported on his efforts as 
editor. He had solicited 100 people to write 
articles/book reviews, of which 20 were commit¬ 
ted for contributions in upcoming issues. He was 
working with the staff on revamping the news¬ 
letter’s design and contents. 

Executive Director’s Report. Young re¬ 
ported that the books program had made little 
progress, and Marc Donner had indicated that he 
would no longer have the time to be Editor. After 
some discussion it was decided that no funds 
would be expended on this program until Young 
and O’Dell make a recommendation about the 
program at the next meeting. 

Standards Institutional Representative (IR) 
Report. Collinson reported on the previous 
week’s ieee meeting: In response to the concern 
about the number of IRs that exist and the need 
to control their proliferation, the current plan is 
that the ’at large’ membership is going away; 25% 
of the SEC membership will be allowed to be 
’added’ as IRs; and an election will be held an¬ 
nually, replacing half the IRs. The voters will be 
the SEC less the IRs. He felt reasonably sure that 
USENix and EurOpen will be voted in. He also 
gave a brief report on the posix.i group’s work. 
Walli reported that a lot of work is badly coor¬ 
dinated at these meetings, but it is being done. He 
felt the snitch reports are doing well, and there is 
a lot of interest in reporting the real work on 
POSIX. 

Policies. Various proposals concerning the 
policies document were adopted, and in particu¬ 
lar: institute a student registration fee for the 
smaller meetings at $75.00; fees for all workshops/ 
symposia (events with 2 days of tech sessions) be 
the following: $225 for a pre-registered member; 
$290 non-member; $75 student. 

SIGs. Adams reported that he has a docu¬ 
ment that is based on some ACM material. He 
proposed forming a SIG committee which reports 
to the Board and makes recommendations. The 
first task of this committee would be to work on 


language/wording of his draft document, and 
present recommendations at the next meeting. A 
committee of Kolstad, Adams, Geer, and O’Dell 
was formed. 

Software Distribution Tape. Kolstad handed 
out a CD-ROM of free software compiled by Rich 
Morin, who had several suggestions about dis¬ 
tributing it to our members. It was decided to 
suggest to Morin that the Association might pro¬ 
vide advertising for the CD-ROM in exchange for 
providing a discount to our members to purchase 
it. 

Report from EurOpen. Gien reported that 
EurOpen is looking into offering educational sem¬ 
inars, which would bring people up to speed on 
an advanced topic. Nemeth would look into hav¬ 
ing USENix participate in this. Kolstad and Young 
agreed to continue exchanging ideas about each 
group’s publications with Gien. 

World Forum. Shein said he had discussed 
this topic with EurOpen, who saw the World 
Forum as a way to coordinate events, standards 
activities, and tutorials. Gien explained that 
World Forum is presently just an idea, and will act 
as a formalized mechanism for the dissemination 
of information between its individual member 
organizations/associations. Shein felt that maybe 
we should get involved, gather objections, poll 
the Board, and come back to World Forum with 
a compromise on their previous request for us to 
join. A long discussion ensued regarding why US¬ 
ENIX should be involved and what were the ben¬ 
efits. It was decided that Johnson, Young, Nem¬ 
eth, O’Dell and Shein would attend the World 
Forum meeting on Tuesday and report back to the 
Board at the next meeting. 

Next Meeting. It was decided to hold it at the 
Pike’s Peak Conference Center in Colorado 
Springs on March 30 and 31 with Boulder as a 
backup. Johnson, Kolstad, Gould and Young 
would work on the agenda for this meeting. 

- EY 
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Building and Managing the Interop ’91 Shownet 

Brent Chapman 

Great Circle Associates Brent@GreatCircle.COM 


Interop is a yearly networking trade show, 
considered by many companies in the networking 
trade to be the “event of the year.” In 1992, 
Interop moves to a twice-yearly format. One of 
the key features of Interop is that all exhibitors at 
the show are connected to the “Shownet” so that 
multi-vendor interoperability is actually demon¬ 
strated, rather than simply talked about. The 
Shownet is planned, built, and run by volunteers 
from the industry. 

Last year’s Interop conference, held October 
7-11, 1991 in San Jose, drew over 32,000 attend¬ 
ees. The exhibits completely filled the San Jose 
Convention Center (all 3 large exhibit halls, the 
ballroom, and the concourse area in front of the 
exhibit halls), as well as the Diamond Pavilion 
across the street. When completed, the Shownet 
included over 300 vendors, over 400 subnets, and 
uncounted hundreds of hosts. 

The Shownet was a large, diverse network 
that included many types of physical media. These 
included unshielded twisted pair wire, shielded 
twisted pair wire, fiber optic cable, and coax ca¬ 
ble, as well as T1 and microwave links. When the 
Shownet was finished, it consisted of over 30 miles 
of UTP wire, over 5 miles of fiber optic cable, 
over 4 miles of STP wire, over 1 mile of coax, and 
untold thousands of modular connectors. 

The underlying network consisted primarily 
of Ethernet, Token Ring, and FDDI, but many 
special “demo groups” ran demonstrations of 
other technologies, including Frame Relay, 
ISDN, and SMDS. The primary network proto¬ 
cols used were IP and OSI, but again, many demo 
groups demonstrated other technologies. OSPF 
was used for routing on the Shownet backbone. 

The network was organized into 30 or so 
“ribs.” In the main exhibit halls, the ballroom, 
and the Diamond Pavilion, ribs were UTP Ether¬ 
net and Token Ring runs for the exhibitor booths 
in one or two aisles. At the head of each rib was 
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a pedestal containing the lOBaseT concentrators 
and router for that rib. 

The concourse area consisted of three Thin- 
Net (rather than UTP) ribs, each with a router at 
the end. The ribs were further grouped into four 
“backbones,” one for each of the 3 main Con¬ 
vention Center exhibit halls running along the 
front of the exhibit halls, and one in the Diamond 
Pavilion across the street (the ballroom and con¬ 
course areas were attached to whichever main 
exhibit hall backbone happened to be closest). 
The rib routers in each backbone were connected 
via FDDI over fiber optic cable. 

Each Convention Center backbone was con¬ 
nected via another router to the central network 
in the Network Operations Center (NOC), which 
was located in one of the “skybooth” offices that 
overlook the main exhibit floor. The Diamond 
Pavilion backbone was connected to the main 
network via a T3 link. A microwave link con¬ 
nected the terminal room in the Fairmont Hotel 
with the main network. The Shownet was con¬ 
nected to the Internet through a T1 link to B ARR- 
Net. 

The group that designed, built, and managed 
the Shownet was composed of a small handful of 
paid Interop employees, and a larger group of 
volunteers who traded their time for the invalu¬ 
able experience of working on such a network. 
There were three main groups of volunteers; the 
Core Team, the Shownet Team, and the Shownet 
engineers. 

The Core Team comprised nine individuals 
who were ultimately responsible for the net and 
who worked year-round (starting shortly after the 
previous year’s Interop) to design and build the 
net. They could be considered the “upper man¬ 
agement” of the Shownet. 

The Shownet Team consisted of 20 to 30 
more people who worked primarily during the 
major activity periods (the cabling party in July, 
the hot stage in August, and the actual show in 
October; all discussed below) and were the “staff’ 
of the Shownet. These could be considered the 
“middle management” of the Shownet. 
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Finally, and perhaps most importantly, there 
were the hundreds of volunteers who provided 
labor during the maximum effort periods such as 
the 8-hour period at the start of the show when 
the physical network was installed. The Shownet 
would not have been possible without these folks. 

The Core Team started planning the 1991 
Shownet shortly after the close of the the previous 
year’s conference. By late June, they had devel¬ 
oped detailed plans for exactly what the Shownet 
was going to look like this year. The Core Team 
and the Shownet Team, plus a number of volun¬ 
teers, spent the week of July 4 in the San Jose 
Convention Center (when there was no other con¬ 
ference or exhibition using the facility) laying out 
the physical network. The various wires were 
measured, cut, terminated, tested, labeled, and 
bundled into ribs. The ribs were rolled onto cable 
spools, to be stored until reassembly just before 
the show opened in October. 

Vendors providing equipment for use in 
building the Shownet were required to deliver the 
equipment by mid-August, and in late August, 
the Core Team and Shownet Team gathered 
again, along with vendor technical representa¬ 
tives, for a “hot stage” event at the Interop ware¬ 
house. At the hot stage, all network equipment 
was assembled into the pedestals, configured, and 
tested. The backbone connections were config¬ 
ured and tested as well. The purpose of the hot 
stage was to discover and work out the inevitable 
small compatibility problems in multi-vendor in¬ 
stallations. 

In October, the weekend before the show, 
the Core Team, Shownet Team, and the volun¬ 
teers gathered again to install and test the net¬ 
work. On Friday night, the Diamond Pavilion was 
set up, and served as something of a test case for 
the procedures that were going to be used to set 
up the Convention Center on Saturday night. 

Setting up in the Convention Center was 
tricky, because the prior show (the Seybold Desk¬ 
top Publishing conference) didn’t release the 
show floor to Interop until midnight Saturday, 
and the network cabling that was going up to the 
ceiling had to be completely done by 8 a.m. Sun¬ 
day, when the carpet would be laid down and the 
booths assembled, and the exhibitors would start 
arriving to assemble their booths. 


Eight hours is not a lot of time to wire a 
network that size, and it would have been im¬ 
possible if not for the careful planning and the 
several days spent in the Convention Center in 
July, pre-constructing all the overhead cables. 

The Core Team and the Shownet Team spent 
Sunday through Tuesday configuring, testing, and 
debugging the network. The exhibition floor 
opened to conference attendees on Wednesday; 
by that time, everything was basically working. 
The two teams spent Wednesday through Friday, 
while the exhibition floor was open, trouble¬ 
shooting minor problems that cropped up. After 
the show closed, pretty much the reverse process 
took place to disassemble everything. 

There were a number of lessons to be learned 
from working on something like the Interop 
Shownet. First, detailed advance planning pays 
huge dividends. In particular, if not for the de¬ 
tailed advance planning that went into this 
project, it wouldn’t have been possible to meet 
the time constraints (especially that the physical 
network had to be put in place in only 8 hours). 

Second, simplicity is important and valuable. 
For example, as much as possible was done to 
make the cable plant as generic as possible, by 
pushing wiring differences all the way to plugs or 
patch cords at the ends of connections, so that any 
UTP cable could be used for any purpose, merely 
by changing what it was plugged in to. Addition¬ 
ally, large and complex tools such as SNMP net¬ 
work management systems were avoided, because 
they weren’t really needed. There wasn’t time to 
establish baselines for SNMP performance mon¬ 
itoring, nor was SNMP mapping of the network 
required (the network had just been constructed 
so the Shownet Team and the Core Team knew 
exactly what it looked like). The Shownet was 
managed with ping, telnet, traceroute, and hand¬ 
held 2-way radios. That’s not appropriate for 
many situations, but it was here, because the 
situation was highly dynamic yet very short lived. 

Third, redundancy is also important and 
valuable. The Shownet designers included lots of 
extra wire pairs in their plans; they didn’t really 
have a use in mind for these pairs at the time, but 
they realized that it would be much easier to 
bundle extra pairs in when the network was being 
built, and then not use them, than to discover 
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after the network was already hung on the ceiling 
that they needed more pairs to cope with some 
unexpected problem or request. As another ex¬ 
ample of designed redundancy, there were two 
UTP drops to each booth on the main exhibit 
floor, an “Ethernet” drop and a “Token Ring” 
drop; almost all exhibitors used only the Ethernet 
drop, and the Token Ring drop was in fact in¬ 
tended all along primarily as a backup Ethernet 
drop, in case something went wrong with the 
primary. Finally, all FDDI fiber optic backbone 
connections were backed up with UTP Ethernet 
connections, in case the FDDI fiber connections 
didn’t work for some reason. 

Fourth, pre-planned fallback strategies are 
important and valuable. The Interop Shownet had 
several fallback strategies for various services. For 


instance, if the fiber backbone had failed, a plan 
was in place to fall back to an Ethernet backbone; 
if OSPF routing hadn’t worked, a plan was in 
place to fall back to RIP; and so forth. 

Working on the Interop Shownet was quite 
a learning experience for me. I had an opportu¬ 
nity to work on and learn about a wide variety of 
equipment and technologies, as well as to work 
with and learn from some truly outstanding net¬ 
work planners and managers. Finally, there’s a 
great feeling of accomplishment in seeing the net¬ 
work come together and knowing that you had 
something to do with its success. If you’re inter¬ 
ested in being a Shownet Volunteer next year, 
contact Nan Dorio at Interop (415/962-2539, 
nan@interop . com ). 


Practice and Experience 

Voices and FAXes and UNIX (Oh my!) 

Douglas L. Pintar, Interactive Systems Corporation(dougp@ico.isc.com) 


The author’s experiences building an Inter¬ 
active Voice Response (IVR) system with FAX 
generation are discussed. The motivations, system 
components, tools, and lessons learned are de¬ 
tailed. 

History and Overview 

In May of 1990,1 began work on a computer 
system designed to aid realtors in setting up show¬ 
ings of properties to prospective buyers. This 
work has been done for my own small company, 
Return Communications Companies, Inc., in my 
spare time from Interactive Systems and real life. 
The system as envisioned required several coop¬ 
erating processes to handle incoming and outgo¬ 
ing voice calls, dialins for database access and 
update, FAX generation, and system administra¬ 
tion. Since I had worked on ISC’s port of AT&T 
System Vr3.2 to i386-based computers, ISC UNIX 
on a 386 ISA bus machine was a logical choice for 
a multi-user platform for the system. 


We have been informed that Realtor is a registered 
trademark. 


The On-Call system (as it has become 
known) has a database of realtors and their agen¬ 
cies who can use the system. It stores up to seven 
phone numbers (FAX included) at which they 
may be contacted. In addition, another database 
of properties, keyed by Multiple Listing Service 
(MLS) ID numbers, is maintained. For each, a 
description of how showings are to be set up 
(notify the seller, call the listing agency, seller 
must approve each, no notice required) as well as 
what times they are permitted is kept. The system 
can attempt to reach sellers at home or 
at up to two work phone numbers if necessary, 
depending on day and time. Data entry and 
update is accomplished using a forms-based 
(through curses) program via dialin data lines. 
REALTOR ™s use voice phones to request show¬ 
ings and are given their showing instructions by 
return voice or FAX call. 

Hardware 

We use ISA-bus computers due to the wide 
variety of peripherals available. We currently use 
Gateway 2000 386/25 machines, although produc¬ 
tion installations will probably use 15-20 slot 
rack-mount systems. Bulk I/O is all SCSI-based 
(for low overhead) using Adaptec SCSI adapters. 
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The system uses voice processing boards 
from Dialogic Corporation of Parsippany, New 
Jersey. They make 2-, 4-, and 12-port boards and 
have UNIX drivers available. The boards can gen¬ 
erate and recognize DTMF or MF touch-tones as 
well as rotary dial pulses, and all come in flavors 
that support Dialogic’s Call Analysis feature. This 
enables supervision of outgoing calls to determine 
whether (and how) they are answered. 

We use a Hayes JT-FAX 9600 FAX modem 
controlled by FaxiX software from PC Research 
of Tinton Falls, New Jersey. Rick Richardson, the 
author of this system, has since sold it to Digi- 
board (Eden Prairie, Minnesota) and now works 
for them. Digiboard sells a new version known as 
DigiFAX, which I haven’t tried yet. 

We are currently using a GTEK (Bay St. 
Louis, Missouri) PCSS-8I intelligent multiport se¬ 
rial card. I updated their Xenix driver to run 
under ISC Unix and returned it to them. We will 
probably change over to 16-port (or more) serial 
cards for the production system. 

Tools 

One of the first things you need to get started 
in voice applications is what’s known as a prompt 
editor. This piece of software allows you to record 
spoken phrases, cut out unneeded parts (like be¬ 
ginning and ending silences) and arrange the 
pieces into usable files. Since prompt editors for 
UNIX sell for around $1,000 (and we were trying 
to save money), I wrote my own. The Dialogic 
voice driver allows the seamless concatenation of 
pieces of various files for playback. To utilize this 
capability, I developed a file format that is basi¬ 
cally a quick ’n dirty ISAM. Spoken words and 
phrases are recorded into standard Unix files with 
a utility that allows margins to be moved in from 
the beginning and the end until the desired ut¬ 
terance is contained between them. These files are 
combined into a single file, each with a symbolic 
name, up to 24 characters in length. A library 
routine converts symbolic names into Dialogic- 
style offsets and lengths so that desired phrases 
may be inserted into prompts played over the 
phone. The ISAM file for On-Call contains al¬ 
most 900 individual utterances and occupies about 
7.5 MB of disk (about 41 minutes of speech). 

Each prompt played by the system is gener¬ 
ated from an array of the symbolic names of the 


phrases needed. Null strings are used as place 
holders for non-constant information, such as spo¬ 
ken names, dates and times, and numbers. Li¬ 
brary routines assist in constructing dates, times, 
and cardinal or ordinal numbers. An example of 
a prompt is: 

<selling agent nane> of <selling agent 
agency> r who had a showing scheduled 
for <old starttine> 
today 
tomorrow 
on <date> 

would like to reschedule. The new time 
would be from <starttime> to <endtlme> 
today 
tomorrow 
on <date>. 

To allow the showing, press 1. To deny 
the showing, press 2. To hear the 
message again, press 3. 

The items in angle brackets are filled in and 
a single line of the items stacked vertically is used, 
as appropriate. 

The FAX subsystem is an extension of the 
troff text formatter. It also includes a queueing 
system to handle multiple requests to the single 
FAX modem as well as retrying requests to busy 
FAX machines. On-Call generates mm style 
source text in a relatively simple “fill in the 
blanks” format. The only tool necessary to send 
this is a simple 60-line shell script to generate and 
send the FAX image and maintain a log of those 
sent. 

The remaining tools developed were used to 
generate the initial realtor database from state- 
provided records (obtained, interestingly, from an 
AT&T 3B2 UNIX system!) and to provide termi¬ 
nal access to that data. I developed a custom 
client-server database system tailored to the types 
of data we need. A comprehensive forms-oriented 
update and access program was written using the 
curses package to provide terminal independence. 
The update program is designed to be used with 
minimal instruction and provides two lines of 
context-sensitive help at the bottom of the screen. 
The help provided changes depending on the data 
field selected. 

Lessons 

We had a number of difficulties trying to get 
a computer system to be flexible and easy to use 
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over the telephone. A great many of the problems 
encountered were due to the wide variety of tele¬ 
phone key and PBX systems in use at the various 
offices we deal with. Some of these produce very 
short tone bursts regardless of how long a phone 
key is pressed. These can be missed by the voice 
boards when they are playing prompts, unless the 
sensitivity of the board is increased significantly 
over the default values. This has the unfortunate 
side effect of misinterpreting some spoken words 
as if they were incoming button pressings. We’re 
still looking for a balance between the vocabulary 
used, adjustment of sensitivity depending on 
what’s being played, and tolerance of our users 
when they can’t break through prompts. 

Some phone systems trap the “special” keys 
(* and #) and don’t pass them on when pressed. 
This can be particularly annoying when inputting 
for variable-length fields such as dates and times 
that would normally be #-terminated. I imple¬ 
mented a variable-timeout approach that allows 
about 10 seconds for the first digit of a field to be 
entered. If this timeout is exceeded, a help mes¬ 
sage is played followed by the requesting prompt. 
Once the first character is received, the timeout 
is shortened to about 2.5 seconds. Our experience 
is that a person entering a multi-digit number will 
usually enter the digits fairly closely spaced in 
time, so any delay exceeding this limit is inter¬ 
preted as the end of the number. To speed pro¬ 
cessing, the # key, if available, can be used to 
terminate variable-length fields. 

We had our share of troubles with old phone 
lines. (Our office is in the downtown section of 
Boulder, Colorado and phone company repair 
personnel told us we were connected to some of 
the oldest wires in town.) After some prodding, 
U.S. West has rewired a major portion of the 
neighborhood and our problems from crosstalk 
and open/noisy lines have disappeared. We also 
discovered unique things about cellular phones 
(no busy signals — a recording tells you the called 
party is busy!) and voice mail systems (wonderful 
for computers to talk to once you know for sure 
that’s where you are). 

One real estate company kept tying up all our 
voice lines. It turned out that their internal key 
system had been programmed to automatically 
put a line on hold when the button for another line 
was pressed. The agents at that office had gotten 


into the habit of using this technique to switch 
from one outgoing call to another, counting on 
the person at the other end to recognize that the 
conversation was over and hang up. Our system, 
when left hanging on the first line, would patiently 
give help message after help message to the as¬ 
sumed confused caller. After about 20 minutes it 
would finally give up and hang up on its own (this 
time could have been shortened considerably by 
doing fewer retries, but we were still testing). The 
company involved had no idea their phone system 
was behaving in this ill-mannered way! 

We discovered that it was important to make 
sure casual users of the system had at least some 
training. We received a call from an irate agent 
telling us the system had never delivered her in¬ 
structions for showing, and she was about to leave 
for the showings empty-handed. We checked the 
logs and discovered they’d been FAXed to her an 
hour prior to her call. When we told her this, we 
heard rustling of papers on the phone and a quick, 
“OK, goodbye.” She had been looking for a 
phone message from her receptionist instead of a 
FAX! 

Conclusions 

Despite a longer-than-anticipated learning 
curve, our system seems to be ready to go. We are 
currently working with a number of Boards of 
Realtors for various areas in Colorado, and hope 
to have our first commercial system running by 
3Q92. A number of people have been surprised 
when hearing that we’re using UNIX as a platform 
for telephone speech work. They assume that 
DOS would be the OS of choice, given its small 
size and reputation for “real-time” event han¬ 
dling. However, Dialogic’s tests have shown that 
386-based Unix systems can support 60 simulta¬ 
neous voice lines with ease. We anticipate systems 
with up to 48 voice and 32 dial-in serial lines will 
be commonplace. I would hate to contemplate 
having to write the multitasking, interprocess 
communication, and memory management that 
we get for free from Unix. The terminal inde¬ 
pendence provided by terminfo and curses makes 
handling a wide variety of data input terminals 
simple, and we can easily add additional system 
RAM (up to 256MB on an EISA box) and thou¬ 
sands of megabytes of disk as needed. The da¬ 
tabase engine is ready to run on a server system 
of its own, with the only change being to substi- 
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tute TCP/IP sockets for the message queues now 
being used between the library routines and 
server top end. In addition, having tools like sees 
and make available has made dealing with the 

The Bookworm 

Peter H. Salus, Sun User Group 
peter@sug.org 

[Preface: For a long time I have felt that the 
news about current print materials takes too long 
to get to the technical and professional user. As 
a result, I intend to write regular brief book re¬ 
views in this space in login . These may not be 
extensive, but I hope that they will be informa¬ 
tive. Peter] 

Up to very recently, the only way to acquire 
information about GNU Emacs was through the 
manual written by Richard Stallman around 1985, 
and updated several times (my copy is “Sixth 
Edition, Version 18, March 1987”). As the pop¬ 
ularity of GNU Emacs has grown, the need for a 
book has been perceived. While four have been 
published recently, two have struck my fancy. 

Michael A. Schoonover, John S. Bowie and 
William R. Arnold, GNU Emacs: UNIX Text Ed¬ 
iting and Programming (Addison-Wesley, 1991) is 
a monster of a volume: over 600 pages of which 
about 100 are a genuine “Command Reference” 
guide. What Schoonover and his colleagues have 
attempted is to place introductory and advanced 
material in the same volume. To my amazement, 
they have succeeded. Thus, if you already know 
some Emacs, you can skip the “Basic Tour” and 
go to “Advanced Editing” or “Customizing.” 

One of the things I liked a lot was the set of 
chapters on program development: in C, in FOR¬ 
TRAN, in Lisp, in Pascal. The Command Ref¬ 
erence is great. 

Debra Cameron and Bill Rosenblatt, Learn¬ 
ing GNU Emacs (O’Reilly and Associates, 1991) 
is under 400 pages. It does not contain the sort of 
detailed command reference that Schoonover’s 
book does, but it may be right book for real 
learners. It contains a good deal of information 
about windows and buffers that is not as readily 
available in Schoonover. It also contains material 
on editing Scribe, which isn’t in the other volume, 


56,000 lines of source code manageable. To para¬ 
phrase an orange juice commercial, “UNIX — it’s 
not just for workstations anymore!” 


as well as stuff on the LPF, the GNU public 
license, the GNU Manifesto, and a well-written 
introduction. 

For a real introduction, parts of Cameron 
and Rosenblatt may be the thing; for a thorough 
work whose authors understand that Emacs is a 
programming environment, I prefer Schoonover, 
Bowie and Arnold. But there’s no question that 
both are welcome additions to the (sparse) list of 
books on working with a group of large African 
antelopes with “horns in both sexes” (Webster’s 
Collegiate Dictionary). 

Aeleen Frisch’s Essential System Administra¬ 
tion (O’Reilly & Associates, 1991) is reasonably 
well-written and easy-to-read. It states that it’s 
not written for UNIX wizards, and it isn’t. While 
I think that it can easily serve as a painless in¬ 
troduction to an area many of us would rather not 
know about at all, it will hardly replace Nemeth, 
Snyder and Seabass (1989). Further, there are 
several places where things are dramatically over¬ 
simplified (e.g., the UNIX history chart, p. xvi). I 
wasn’t at all thrilled by the bibliography, which 
omits Nemeth et al. At first I thought that this 
might be an attempt at not listing things that ORA 
hadn’t published. But then I realized that this was 
false, that ORA is a solid and honest publisher: 
otherwise, why would they list John Quarterman’s 
The Matrix and omit Frey & Adams’ !%@:, 
which ORA published in 1989? It’s unclear to me, 
too, why Bach’s fine volume on the UNIX OS is 
there, but Leffler, McKusick, Karels and Quar- 
terman isn’t. In the ORA tradition, there is an 
armadillo on the cover of Frisch’s book. I rec¬ 
ommend Kipling’s Just-So Story on the origin of 
armadillos to all of you. 

Steve Oualline’s Practical C Programming 
(ORA, 1991) is really quite useful. Covering not 
only ANSI C and PCC, but also (gasp!) Turbo-C 
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for MS-DOS, Oualline talks about style, debug¬ 
ging, the environment (though the reader will 
need help if developing C in Emacs), syntax, 
optimization, and the like. The illustrations are 
first rate. If you know someone who’s never pro¬ 
grammed in C, this may be the book for her/him. 
I was especially taken by the good description of 
bit-mapping and of the way make was introduced 
early on, and then elaborated in later chapters. 
Unfortunately, there is neither a history of the 
language nor a bibliographical reference to K&R. 
Brian and Dennis deserve better than this. De¬ 
spite this, I think Oualline has done a job he can 
be proud of. 

As C++ has, in some ways, become a dom¬ 
inant object-oriented programming language, it’s 
nice to see a book like Scott Meyers’ Effective 
C++ (Addison-Wesley, 1992). This is emphati¬ 


cally not a book for beginners: it is a book that 
focusses on ways for improving programming. Be¬ 
ginning with “Shifting from C to C++Meyers 
itemizes 50 ways to improve programs and de¬ 
signs. He assumes that you are familiar with C++ 
Release 3.0 and (perhaps) Stroustrup and Ellis’ 
Annotated C++ Reference Manual . But Meyers 
can explain how you might choose between in¬ 
heritance and templates; between function over¬ 
loading and parameter defaulting. There’s some 
very informative material on dynamic memory 
allocation. 

This is really a fine example of what an ad¬ 
vanced book should be: it yields both design guid¬ 
ance and programming information. 

Finally, after both Oualline and Meyers: 
could someone find something to print besides 
“Hello, world”? 


Book Reviews: 

Learning GNU Emacs 

by Debra Cameron and Bill Rosenblatt 

O’Reilly & Associates, 1991, 

ISBN 0-937175-84-6 

Reviewed by Linda Branagan , Convex Computer Corporation 


For a couple of years now, I’ve been starting 
conversations with fellow UNIX users by asking, 
“What’s the worst piece of documentation you’ve 
ever encountered?” The answers I’ve gotten 
range from the bizarre (“the source” to the benign 
(“the at man page”), and a handful of documents 
get mentioned with startling frequency. 

I haven’t kept careful records, but I’d bet that 
the GNU Emacs Manual is one of the top five 
vote-getters — and somehow, this doesn’t sur¬ 
prise me. I’ve battled with my own copy plenty of 
times and it certainly bears the scars — it is often 
only with the help of scribbles in margins, folded- 
over pages, and half a dozen yellow sticky-it notes 
that I find what I’m looking for. Fortunately, the 
latest offering by O’Reilly & Associates, Learning 
GNU Emacs, provides an alternative. 

Authors Debra Cameron and Bill Rosenblatt 
do a particularly admirable job presenting the 
extensive functionality of GNU Emacs in well 


organized, easily digested chapters, without once 
resorting to sections titled “Miscellaneous Com¬ 
mands.” Early chapters cover the basics: manip¬ 
ulating text, searching, and using buffers and win¬ 
dows. Casual or unadventurous users can learn all 
they need to know in the first 90 pages or so. 
Chapter 5 is titled “Emacs as a Work Environ¬ 
ment” and describes facilities for reading and 
sending mail, executing shell commands, manip¬ 
ulating the contents of directories, and reading 
man pages. A subsequent chapter explains Emacs 
extensions for the X Window System. 

Extensibility is possibly Emacs’s strongest 
suit, and considerable attention is paid to it in the 
book. There is a chapter devoted to writing mac¬ 
ros and another titled “Customizing Emacs” 
which describes useful customizations that require 
no knowledge of programming. For readers who 
want to know more, there is an outstanding in¬ 
troduction to Emacs LISP Programming. How¬ 
ever, if you plan on writing anything complex, 
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you’ll probably need the GNU Emacs LISP Ref¬ 
erence Manual or some other LISP book. 

For those who must know, the Towers of 
Hanoi, Eliza, Zippy the Pinhead, and other 
amusements are described briefly in Appendix D. 
(M-x psychoanalyze-pinhead gets by unmen¬ 
tioned, but I don’t want to think about the type 
of person who might be upset by this fact.) 

Despite its title, Learning GNU Emacs could 
easily serve as a reference for the experienced 
Emacs user. Related commands and functions 
often appear in tables and can be easily located 
through either the index or the List of Tables. 
Appendix C lists all the variables discussed in the 
book. A quick reference is provided in Appendix 
H, although at ten pages, I have to wonder if 
“quick reference” is really the right term. 


Appropriate credit is of course given to the 
Free Software Foundation. In addition to the en¬ 
tire text of the GNU Public License, there is also 
a brief explanation of the GNU Manifesto, a gen¬ 
tle reminder that the FSF is always interested in 
donations of hardware, time, or money, and a 
refreshingly unzealous description of the League 
for Programming Freedom, along with a mem¬ 
bership form. 

Like most of O’Reilly’s Nutshell Handbooks, 
Learning GNU Emacs is written in a friendly, 
straightforward style. Screen examples are nu¬ 
merous in introductory chapters and appropri¬ 
ately rare in later ones. The page design is clean, 
and so far I’ve found only one typographical error 
and one index entry that is off by a page. It’s 
printed on recycled paper — a trend I hope more 
publishers will notice and follow. 


Inside Smalltalk, Vols 1 & 2 

by Wilf R. LaLonde and John R. Pugh 

Prentice Hall 

Volume 1, 1990, ISBN 0-13-468414-1 
Volume 2, 1991, ISBN 0-13-465964-3 

Reviewed by Tom Wadlow, Sun Microsystems Laboratories, Inc. 


Smalltalk is often cited as one of the pro¬ 
genitors, if not the main one, of object-oriented 
programming. It was invented at the Xerox Palo 
Alto Research Center in the 1970s, and has gone 
through a number of evolutionary phases to be¬ 
come the programming environment it is today. 
There are many good reasons to study Smalltalk 
and its development environment, not the least of 
which is that it is fun for writing programs. 

One aspect of using Smalltalk that is cited 
again and again, by advocates as well as detrac¬ 
tors, is that learning to use the Smalltalk system 
involves climbing a fairly steep learning curve. 
The reason for this is two-fold. First, object- 
oriented programming (OOP) is very different in 
philosophy from more commonplace program¬ 
ming philosophies, such as the procedural style 
embodied by C or Pascal. To be productive in an 
OOP system, you have to relearn your sense of 
style and your feel for design esthetics. This is not 
an easy thing to do and it takes time to get it right. 
But the need to do this is shared by all OOP 


systems, including C++. Second, you must learn 
to use the environment. There are a lot of tools, 
and while they often share a common heritage and 
feel, you have to learn to find them, start them, 
and to understand what they can do for you. In 
this, learning Smalltalk takes longer than learning 
C++, precisely because Smalltalk has a whole 
toolkit that one must learn, and many prefabri¬ 
cated components that one can use, while C++, 
in and of itself, does not. 

The Inside Smalltalk series addresses itself to 
the second of these two issues. Inside Smalltalk is 
a guided tour through the Smalltalk-80 program¬ 
ming environment, in particular version 2 of 
Smalltalk-80 as sold by ParcPlace Systems. The 
two volumes contain a small amount of tutorial 
information on the general philosophy of object- 
oriented programming, and a large amount of 
illustrated and commented walks through the pro¬ 
gramming environment and the object hierarchy 
that is included with the system. 
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Volume One contains the most generally use¬ 
ful sections for a Smalltalk programmer, namely 
some extensive discussions of the tools, such as 
the System, Class and File Browsers, the Inspec¬ 
tors, Notifiers and Debugger, and an introduction 
to the basic object classes. 

Volume Two concerns itself with the Small¬ 
talk graphical user interface, and the famous 
Model-View-Controller paradigm that it uses. In 
addition, this volume gives a number of example 
programs that one could add to the system, in¬ 
cluding a librarian for bitmapped images, and a 
user interface construction toolkit that one can 
use to create more of one’s own applications. 

Each volume covers a well-chosen set of top¬ 
ics, and very little cross-volume referencing is 
done. So it would be possible to buy one without 
the other. However, both cover useful and inter¬ 
esting topics and anyone intending to do serious 
programming in Smalltalk is likely to run into 
issues that are covered in both volumes. 

Both volumes do a good job of walking 
through the code of various classes and applica¬ 
tions and explaining what is happening. They 
would be very useful for someone who intends to 
write a great deal of Smalltalk, because they cover 
in a uniform fashion what most Smalltalk pro¬ 
grammers tend to learn piecemeal, namely the 
inner workings of the major classes. However, 
that coverage is a bit too dense for novice OOP 
programmers to use these books alone as a means 
to learning Smalltalk. As an example, consider 
the description of the Collection classes, possibly 
one of the most powerful tools available to the 
Smalltalk programmer. The description of these 
classes contains a great deal of enumeration of the 
various types and the messages that one might 
send to each type. There is a nicely organized 
collection of hierarchy diagrams that show you 
how the classes interrelate, but there is very little 
text devoted to telling you what the classes are 
for. To a Smalltalk programmer with even just a 


few days of exploration or instruction under his or 
her belt, much of that explanation is not needed. 
And a novice will be utterly baffled by what is 
being said. 

The authors also recommend that their books 
be used in conjunction with access to a 
Smalltalk-80 system. This is excellent advice since 
most of the fun and power of Smalltalk is avail¬ 
able only with hands-on experience to that sys¬ 
tem. It would be possible to use another dialect 
of Smalltalk such as Smalltalk/V by Digitalk, be¬ 
cause much of code design is similar, however 
there are distinct differences as well that may be 
a source of confusion. 

One other source of confusion, for which the 
authors are not responsible, but of which the 
reader is warned nevertheless, is that the forces 
of the marketplace have moved somewhat past 
these books. Smalltalk-80 no longer resembles the 
system described in these books, at least at a 
surface level. The newer version is more flexible, 
and has a more modern graphical user interface. 
Much of the flavor conveyed in these books re¬ 
mains, however, but there are certain to be sig¬ 
nificant differences. Still, much as last year’s road¬ 
map is still useful this year, these books are still 
a helpful guide to the even more interesting place 
Smalltalk-80 has become. 

The people who will be happiest with this 
book set are those who have a reasonable famil¬ 
iarity with the ideas embodied in the OOP style, 
who have a basic conceptual grasp of the workings 
of Smalltalk, or access to a basic tutorial, and who 
now want to dig deeper. Recommended. 

Tom Wadlow is the Network Manager for Sun 
Microsystems Laboratories, the research arm of 
Sun . His job is to think of ways to push more bits 
faster while staying just ahead of the people who 
decide which bits to push. He has done this sort of 
thing, amongst many other strange things, at Parc- 
Place Systems, Xerox PARC, Schlumberger and 
the Lawrence Livermore National Lab. 
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Book Review: 

The Design and Implementation of the 4.3 BSD UNIX 
Operating System Answer Book 

by Samuel J. Leffler and Marshall Kirk McKusick 
(Prentice Hall, 1991, 85pp, ISBN: 0-201-54629-9 

Reviewed by George Neville-Neil, University of California at Berkeley 


Since 1989 , there have been some unanswered 
questions in the UNIX community. These questions 
were posed to us in a book called, The Design and 
Implementation of the 4 f 3BSD UNIX Operating 
System. Now, the answers are out. 

In The Design and Implementation of the 4.3 
BSD UNIX Operating System Answer Book you 
will find all the answers to the exercises that were 
given at the end of each chapter of the original 
book. 

When I first got the book and saw that it only 
had eighty-five pages, I figured this would be a 
short read. I attempted to read the book by read¬ 
ing each question and answer in order while keep¬ 
ing the original book close at hand for use as a 
reference. The problem, if it is a problem, is that 
I read a question, thought about it, read the an¬ 
swer, and then thought some more. It’s really a 
fun and fascinating read, but not one that can be 
done quickly. 

Of course, most people will probably want to 
use it as a companion book when teaching a class 
and for this it is well suited. The book is divided 
into twelve chapters, which correspond to chap¬ 
ters two through thirteen in the original book. 
There is also a short preface, as well as a page of 
references, to round out the book. 

In keeping with the system in the first book, 
the questions in the answer book are marked for 
difficulty. The exercises that are unmarked were 
answered directly in the preceding chapter. Ex¬ 
ercises marked with a single asterisk will need 
some thought. Finally, the exercises marked with 


two asterisks are considered to be "... major de¬ 
sign projects or open research questions.” The 
answers given to the two asterisk exercises take 
the form of suggestions on how to begin, and 
where to look when researching the answer to the 
question posed. 

The book, in general, has a conversational 
tone. You get the feeling that the authors are 
answering your questions as if you had asked 
them in person, making the book easier to read. 
There is also a sense of humility in the writing so 
which keeps you from feeling that you are being 
lectured. The authors also admit when they have 
made a mistake, as in chapter 13, question 8: 

Q: The reboot system call causes the system 
to halt or reboot. Give three reasons why this 
system call is useful. 

A: The reboot system call is useful for these 
reasons: 

• Safe halting and rebooting of a system re¬ 
quires support from the kernel. 

• The existence of a system call permits ap¬ 
plications to halt or reboot a system without 
operator intervention. 

• TTie third reason was lost in an improper 
system shutdown. 

In short, I really like this book. I found it to 
be interesting and informative. It is an indispens¬ 
able resource for anyone planning to teach a 
course using the original book. The two books 
should probably be marketed to educators as a 
set. 
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An Update on UNIX-Related Standards Activities 

Stephen R. Walli 

Report Editor, USENIX Standards Watchdog Committee 


[ENOBANDWDTH] — No Band Width Left 

An asynchronous signal was caught (such as 
SIGBALLOT, SIGPLSCOMMENT or SIGMORE2RD; See 
the description of <signal.h> in 3.3.1) while the 
programmer process was busy dealing with the 
last such signal. The current handler shall be in¬ 
terrupted after attempting to save context, and 
the new handler begins to execute. Signals shall 
continue to be delivered, interrupting one an¬ 
other, until {_ posix_ last_ straw} is reached. 
Once the true value of {_ posix_ last_ straw} is 
reached, the entire precarious stack comes clat¬ 
tering down. The last interrupt handler with 
enough context to still maintain some semblance 
of integrity returns CENOBANDWDTH]. A pro¬ 
grammer process may attempt to notify its parent 
process of the condition in an implementation 
defined way, but it shall be ignored. 

All joking aside, POSIX is finally beginning to 
strain the seams of the working groups, along with 
the standards process in which it lives. 

There was a time when posix meant a work¬ 
ing group of around 20 people defining a system 
interface for source code portability, based on the 
C language interface to Unix (356 pages). Then 
it started to grow. 

The shell and utilities were added (~ 900 + 
— 300 pages) making posix. 2 . Someone thought 
conformance testing should be done in a standard 
way, and since they started suspecting POSIX was 
going to grow some more, they decided to make 
a standard for defining test methods (47 pages). 
Then there were the test methods themselves. 
(Another 500 pages each for posix. l and posix.2 
so far.) Then came real-time, to take all the real¬ 
time sorts of things that posix. l couldn’t settle on, 
along with a few things of interest only to the 
real-time community. (Another — 400 pages, plus 
threads.) 

You can continue in this vein for quite some 
time. The posix. 20 (Ada Bindings for posix. 4/.4a 
Real-time services) project has recently started 


up. This doesn’t take into account the other re¬ 
lated IEEE Technical Committee on Operating 
Systems standards (1201 GUIs, P1224 x.400, P1238 
FT AM). 

The working groups now number between 
350 and 400 people, who attend four one week 
long meetings a year. (As an aside, do the back 
of the envelope calculation as to the amount of 
money that represents. Using 350 people, $2000/ 
week expenses, and a loaded staff cost of another 
$1500/week, I get $4,900,000/year.) The working 
groups generate a considerable quantity of read¬ 
ing material, documenting discussions and deci¬ 
sions, reviewing and coordinating with related 
efforts, proposing alternatives, and commenting 
on other proposals. This all on the way to pro¬ 
ducing the actual draft document to ballot as a 
standard. 

An average C programmer or applications 
designer would likely be interested in the base 
interfaces (posix. l), most of the real-time services 
(posix. 4), some security (posix. 6), and possibly 
some of the networking (Transparent File Access 
— posix. 8 , and Protocol Independent Commu¬ 
nications — posix. 12). And of course the shell 
(posix.2/.2a). Whew! That’s a lot of paper, posix 
Zen koan: Does a tree scream in the wilderness 
every time a new project request is approved? 

Before all the Ada and Fortran programmers 
start howling about the “C” programmer refer¬ 
ence, let me explain. Until recently, the Ada or 
Fortran involvement in POSIX has been two small 
working groups who realized very early in the 
game that this standard was going to be extremely 
important. They have each now produced a stan¬ 
dard binding of their respective languages to the 
C-based posix. l standard. 

The Ada working group is now beginning to 
address POSIX.4 and posix. 4a. The Fortran work¬ 
ing group is beginning a Fortran 90 version of 
posix. l (the original posix. 9 standard being an 
F77 binding). These groups are well placed to 
begin opening the way for a large segment of the 
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systems building community that doesn’t work in 
C to gain access to the benefits of a standard 
systems interface. They are, however, the excep¬ 
tions to date, rather than the rule. 

With several vendors delivering posix.i in¬ 
terfaces and posix.2 shells on their non-UNix- 
derived operating systems, the growth of interest 
in posix based open systems is only just begin¬ 
ning. This could bring in a badly needed injection 
of new blood to the posix working groups. But 
these people will not have the often needed his¬ 
torical context. They will require some time in the 
system to come up to speed on all of its perver¬ 
sities. 

Let’s argue that you do care about all of these 
related base standards. (You should! They are 
being forced upon you in many cases.) That 
means you should be involved enough to at least 
ballot. Maybe not every section of every docu¬ 
ment, but certainly sections in each of these 
drafts. You cannot stand by idly trusting that a 
good standard will fall out of the end of the pro¬ 
cess, and you can then use it. If you are a member 
of a technical user group such as usenix, then the 
only difference between you and the people build¬ 
ing the POSIX standards are that they’ve found the 
financial support of their organizations to attend 
the meetings. Think about it. 

If you cannot attend the meetings, then you 
should ballot the draft documents. (Ballot early! 
Ballot often!) But this then brings us back to 


Project 

Ballot 

posix. 0 (Guide) 

1st Ballot 

POSIX. la (More .1) 

1st Ballot 

posix. 1 /LIS 

1st Ballot 

posix. 2 a(UPE) 

3rd Recirc 

posix. 3.2 (.2 Test methods) 

1st Ballot 

posix. 4 (Real-time) 

3rd Recirc 

posix. 4 a (Threads) 

1st Recirc 

posix. 4 b (More Real-Time) 

1st Ballot 

posix. 5 (Ada) 

Final 

posix. 10 (Super. AEP) 

1st Ballot 

posix. 12 (Protocol Indep.) 

1st Ballot 

posix. 13 (Real-time AEP) 

1st Ballot 

posix. 15 (Batch) 

1st Ballot 

posix. 16 (C Binding) 

1st Ballot 

posix. 17 (Direct. Serv.) 

1st Ballot 

posix. 18 (PEP) 

1st Ballot 


[EN0B&HDHDTH1. The balloting schedule for 
1992 (as taken from a balloting status report of 
last December) looks something like the table at 
the bottom of the page. 

A few of these are a little bit specialized, such 
as posix. 10 (Supercomputing Profile), posix. 13 
(Real-time Profiles), posix. 15 (Supercomputing 
Batch Interfaces), and posix. 17 (Directory Ser¬ 
vices). Note, however, that these are the smaller 
documents. And I haven’t mentioned the non- 
posix tcos standards from P1201 (gui), P1224 
(x.400), and P1238 (ftam) that are also sending 
drafts to ballot in 1992. 

After a punishing year of balloting in 1991, 
the Balloting Vice-Chair is staging the drafts so as 
to not completely bury the balloting groups in 
which there is often a lot of overlap. This means 
a working group had better hit its target date, or 
it will be left circling the balloting schedule, look¬ 
ing for another time slot to hit. 

This heavy balloting load is starting to lead 
to the break down of the mock balloting process. 
In the “good ol’ days” a document could be sent 
to mock ballot to test the waters, before com¬ 
mitting to the serious work of a formal ballot. 
With so many documents out for formal ballot, 
most mock ballots are finding themselves at the 
bottom of the pile. [ENOBANDWDTH] 

The heavy balloting of large documents to 
large balloting groups is beginning to take its toll 


Date Size 


July 92 

—250 pgs 

Summer 92 

—100 pgs 

Spring 92 

—400 pgs 

Jan 92 

—300 pgs 

Spring 92 

—500 pgs 

Spring 92 

—320 pgs 

Winter 92 

—200 pgs 

Fall 92 

tbd 

Spring 92 

—300 pgs 

July 92 

-75 pgs 

Fall 92 

—400 pgs 

Spring 92 

-80 pgs 

July 92 

-175 pgs 

Spring 92 

—200 pgs 

Spring 92 

tbd 

Spring 92 

tbd 
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in other ways. The ieee Standards Office can no 
longer absorb the entire cost of copying and dis¬ 
tribution. For the first time in posix’s history, the 
current invitation to ballot is charging a fee per 
document ($25) to join the group. [ENOFI- 
NANCES]? 

We’ve really only touched on the balloting 
load. If you are serious, and you find the fi¬ 
nancing, you can look forward to spending four 
weeks a year in exotic locations like Parsippany, 
New Jersey, at the working group meetings. If 
you stick strictly to a working group or two, you 
will actually be able to get out of the hotel for 
dinner. (Parsippany didn’t have a lot to offer 
here, but then we have been to New Orleans.) 

If you are interested in any of the cross group 
issues, such as Language Independent Specifica¬ 
tions, Conformance Testing, or most important of 
all, the overall structure of the posix standards, 
and the process of building it, you can look for¬ 
ward to six 12 to 13 hour days (not five). 

If you are a serious participant, i.e., you 
actually do work between meetings, you probably 
spend at least another week of your time on posix 
for every week of meeting time. Unless you are 
self-employed, it is unlikely you do this in plain 
sight at your place of business. It’s generally 
frowned upon. After all, your manager already 
feels he’s paying for you to attend four of these 
“conferences” a year. [ENOSUPPRT]? 

It is often surprising to discover how little 
corporate support exists for people in the process. 
There are many stories of people who cannot find 
the consistent support to participate, either moral 
or financial, who work for companies you would 
assume have an obvious stake in posix. While 
their companies love to bask in the glow of their 
“obvious commitment to open systems,” their 
people are put through the wringer trying to get 
the job done right. (Please see the last line of the 
ENOBANDWDTH definition again.) 

So the coming year will be interesting. As 
many of the posix projects reach ballot, the num¬ 
ber of documents circulating in ballot grows. The 
relentless and blind pressure from the market¬ 
place to build more standards faster will grow 
rather than fade. The number of posix projects 
will continue to grow, before we’ve even figured 


out how the current ones integrate. Hark — I hear 
a tree screaming. 

Report on POSIX.6: Security 

[srw—Please note that Dan's report on POSIX.6 
covers the October 1991 , meeting in Parsippany. 
Timing and the Holidays were against me getting 
it published in the last issue with the other October 
reports. Apologies to both Dan and the reader.] 

Daniel D. Ujihara 

<dujihara@EBay.Sun.COM> reports on the 
October 21-25 meeting in Parsippany, NJ: 

The October meeting was a transitional one 
for POSIX.6. After three and a half years in the 
making, posix.6 went out for ballot. Draft 12 
(dated September 1991) was sent to the ieee for 
balloting before the October meeting. 

Since the document is out for ballot, the 
functional subgroups have disbanded and re¬ 
formed into three new subgroups: 

• POSIX.6 futures 

• technical reviewers for the ballot 

• test assertions writers 

POSIX.6 Futures 

The futures subgroup spent much of the 
meeting investigating work items for POSlx.6a. 
They determined that there is interest in the fol¬ 
lowing areas: 

• access controls (integrity, commercial) 

• data interchange formats 

• general terminal interfaces 

• identification and authentication 

• test assertions 

The following areas were rejected: 

• accountability and audit—they are ad¬ 
dressed in the current draft 

° accuracy (i.e. the health of your hardware) 
—the implementor should do this 

• availability 

• language independence specifications 

• temporary access control 

The subgroup has also begun tracking other 
active POSIX groups in which it is interested (i.e., 
posix.0 , posix.4, posix.7 and posix.8). 
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Test Assertions 

There was insufficient critical mass for the 
test assertions group at this meeting, thus no 
progress was made, posix.3 provided training on 
writing test assertions to posix.6 , in an effort to 
bootstrap the process. While this tutorial was well 
received, it revealed that the posix.3 test assertion 
methodology may have to evolve some to accom¬ 
modate the multi-option nature of posix.6 . 

Technical Reviewers 

The technical reviewers spent the October 
meeting defining the procedures and processes for 
ballot resolution. Mike Ressler of Bellcore is the 
technical editor and ballot coordinator for posix.6 
and he has put together a group of twelve tech¬ 
nical reviewers. The reviewers are responsible for 
addressing ballot objections and coordinating re¬ 
sponses between themselves. The ballot coordi¬ 
nator is responsible for making sure each objec¬ 
tion is addressed. 

Future meetings will be dedicated to the res¬ 
olution of any ballot objections, a new project 
request (par) for POSlx.6a, and test assertions for 
POSIX.6. 


Report on POSIX.4, POSIX.4a, 
POSIX.13, POSIX.41). Real-time 
Extensions 

Bill O. Gallmeister <bog@lynx.com> reports on 
the January 13-17 meeting in Irvine, CA: 

Summary 

This meeting, we concentrated on the real¬ 
time profiles document (posix.i3), and on the new 
real-time interfaces (posix.4b). posix.13 was re¬ 
leased to ballot at the end of this meeting. In 
addition, technical reviewers for posix.4 and 
POSlx.4a were able to make good progress on 
their respective drafts. POSIX.4 may complete bal¬ 
loting in the Fall of 1992; POSix.4a will probably 
take another six months after that. Our current 
intention is to ballot POSlx.4b after the October 
meeting. By that time, posix.4 itself should be 
through the ieee balloting process and into an 
ISO ballot, though we will probably still be bal¬ 
loting posix.4a. 


POSIX.13: Real-Time Profiles 

The big news here is that posix.13 is now 
ready to ballot! After a number of small mock 
ballots, the working group closed on what the 
functionality should be in each of the four profiles 
contained in posix.13. posix.13 is the first posix 
profile document to reach ballot. With any luck, 
we will begin posix. 13 ballot resolution at the 
April, 1992 meeting. 

POSIX.4b: New Real-Time Interfaces 

Our goal this week was to settle on the con¬ 
tents of POSlx.4b and to produce first drafts of 
each chapter. We came close. Some first chapter 
drafts should be coming in the mailings. 

POSlx.4b includes chapters for: interrupt con¬ 
trol; timeouts on all blocking functions; enhanced 
memory allocation; sporadic server scheduling; 
spawn (a combined fork/exec); the ability to wait 
on multiple things, also known as event flags; 
CPU time budgeting (the ability to set time bud¬ 
gets for other processes/threads and examine time 
spent by those processes/threads); and more in¬ 
terfaces for driver/application communication 
(i.e., ioctl). Some of these chapters actually did 
make it into the draft by Friday. Other facilities 
were brand new, and are still being debated (CPU 
time budgeting, event flags and ioctl were espe¬ 
cially contentious). The contents are not cast in 
stone, but it indicates the small groups which the 
working group will form at the next meeting. 

Ioctl 

The standard method of driver/application 
communication, aside from the obvious read/ 
write, is ioctl. posix. l elected not to standardize 
ioctl, instead preferring to provide alternate stan¬ 
dard interfaces to control those devices, such as 
TTYs, for which a standard set of ioctls existed. 
For devices which were not standard, POSIX.l did 
not wish to provide a standard interface for doing 
non-standard things. 

There was some agreement with this ap¬ 
proach in posix.4, but the idea had been raised 
that perhaps there were a suitable set of standard 
devices which might benefit from standard ioctls 
(SCSI devices, ieee 488 devices, and so forth). 

A small group (me) gathered up a list of 
standard devices for consideration for a standard 
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ized control interface. Whether the interface was 
ioctl or not is, at this point, largely immaterial. 
When this list was presented, it was rather short; 
it turned out that most of the impetus for ioctl is 
not the desire to perform standard I/O operations 
(rewind a tape, eject a floppy), but rather to do 
non-standard things (rotate a radar, drop some 
control rods, e.g.). We decided to form a small 
group to further explore this issue. 

Enhanced Memory Allocation 

An interface by which memory can be allo¬ 
cated from various special pools (NVRAM, Video 
Ram, for instance) is standard practice in much of 
the real-time community. This is the idea behind 
an enhanced memory allocation interface. It was 
pointed out that the mmap() facility could be used 
to carve off parts of an appropriate memory area, 
and an allocator could be easily constructed at 
application level based on this. This was seen to 
be the correct way of allocating special memory. 

Asynchronous Interfaces 

Some have requested that POSIX.4 provide 
asynchronous interfaces to blocking services. 
Some objected that we have already done so; 
POSix.4a provides an asynchronous interface to 
any system interface by allowing threads to be 
created for the purpose of using those interfaces 
without suspending the original thread. For in¬ 
stance, an asynchronous open routine can easily 
be emulated by creating a separate thread to per¬ 
form a synchronous open, then signal the original 
thread and go away. Despite this, we have an 
agenda bullet to explore this possibility in Dallas 
this April. 

POSIX.4 and POSIX.4a Draft Status 

POSIX.4 has completed its third round of bal¬ 
loting and the ballot objections are dropping off 
in a gratifying fashion. The draft should be out for 
its next-to-last recirculation by the April meeting. 
ieee approval is expected in the Fall of 1992. 
POSix.4a is approaching its next circulation and 
should be recirculated by the Fall meeting as well. 
POSix.4a will actually be reballoted rather than 
recirculated, because it was not able to achieve a 
75% approval rate. This means that the entire 
draft will be open for comment, rather than just 


the parts of the draft that have changed from the 
previous draft. The balloting group, however, will 
remain the same. 

Report on POSIX.5, POSIX.20: 

Ada Bindings 

Del Swanson <dswanson@email.sp.unisys.com> 
reports on the January 13-17 meeting in Irvine, 
CA: 

The POSIX.5 working group is producing an 
Ada binding to the C-based posix.i document. 
The group is also involved with a new project, 
posix.20. This will be an Ada binding to the pro¬ 
gramming language independent specification of 
posix.4 (Real-time Extensions) and POSix.4a 
(Threads). 

The meeting in Irvine was spent on the fin¬ 
ishing touches to the posix.5 document, which is 
finishing ballot, and getting a good start on the 
new posix.20 work. 

The group had been somewhat shocked at 
the overwhelming positive response to the first 
recirculation of the posix.5 document. There was 
almost 90% approval by the almost 300 balloters. 
This is a compliment to the great ballot resolution 
job on the part of the technical reviewers. It was 
a slight embarrassment, however, since there 
were known errors in the draft. In fact, the draft 
had been sent out for recirculation even though 
an error had been discovered at the last minute. 
We assumed that it could be fixed in the next 
recirculation. 

The group decided to “do the right thing”, 
and make one more recirculation with minor ed¬ 
itorial changes and a couple of error corrections. 
Draft 8 is expected to be the final recirculation. 
It should have a fast turn-around, and it is ex¬ 
pected to be approved at the June meeting of the 
ieee Standards Board. 

Several new members have joined the group 
because of their interest in the POSIX.20 binding 
of the real-time extensions. They showed them¬ 
selves to be eager participants, astute observers, 
and acquainted with the issues we will be facing 
in this task. 

The single issue that will demand our atten¬ 
tion more than any other during the binding de¬ 
liberations is how the relationship of Ada tasks to 
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posix.4a threads will be represented in the bind¬ 
ing. As background, most of us are convinced that 
the p-threads as defined in POSix.4a will provide 
an adequate capability for Ada implementations 
to use for a direct mapping of Ada tasks. Further, 
we believe that the services provided in the 
posix.4 materials will be sufficient for a reason¬ 
ably straightforward implementation of Ada task¬ 
ing semantics by Ada runtime libraries. 

Nevertheless, the semantics of tasks are not 
identical to the semantics of threads (for example, 
Ada allows no orphans). Further, since Ada as a 
language introduces concurrency along with the 
rules of interactions, the runtime libraries of Ada 
implementations like to be able to make assump¬ 
tions about the state of tasks. Disrupting this state 
would likely be disastrous. For example, if an 
application directly aborted a thread (which had 
been mapped as a task) the runtime library could 
become quickly confused. 

Opinions about how to deal with this situa¬ 
tion range widely, and tend to be held strongly. 
Some participants believe that services such as 
pthread-create() that are available via language 
construct (declare a task) should not be visible to 
applications by direct call to the operating system. 
Others believe that every interface should be 
made directly visible by way of the Ada binding. 
Many attempts are being made to integrate the 
needs of the various factions. This issue will arise 
in many ways throughout the entire POSIX.20 
project. 

One issue that was resolved was the basic 
character of the binding. The IEEE POSix working 
groups have taken the lead from ISO WG15 (iso 
posix) that all posix standards will be formulated 
as language independent specifications (lis), and 
this will be accompanied by a series of thin pro¬ 
gramming language bindings. While there con¬ 
tinues to be skepticism evidenced by some mem¬ 
bers of the group, who doubt the wisdom (or the 
possibility) of this approach, we agreed that we 
would be converts to the cause. 

We will produce a thin binding to the LIS 
versions of posix. 4 and POSix.4a. We will do so 
enthusiastically. We will help the POSIX.4 working 
group insofar as we can to produce a viable LIS 
version. 

We are fortunate that a couple of our mem¬ 
bers have received funding to give us a head start 


on some labor-intensive activities. The U.S. Navy 
funded a solid first draft of the test assertions for 
POSIX. 5. The U.S. Army funded a first draft thin 
Ada binding (or transliteration) of the existing 
C-based posix.4 document. 

In summary, we are expecting some signifi¬ 
cant progress at our next meeting, now that most 
people are oriented to the issues. Several people 
have volunteered to write position papers, and to 
start working on chapters to present for consid¬ 
eration in April. 

Report on P1224: X.400 API 

Steve Trus <trus@duke.ncsl.nist.gov> reports 
on the January 13-17 meeting in Irvine, CA: 

Summary 

The Irvine meeting was a productive one for 
the P1224 API working group, and we are well 
under way to completing an IEEE standard. 

We worked on and discussed: 

• A recommendation for the International 
Standardization of the IEEE Networking 
APIS, 

• IEEE balloting status for P1224, 

• IEEE balloting plans for P1224.1, 

• The test methods sections for the P1224 and 
P1224.1 documents. 

International Standardization 
Recommendation 

I presented a paper entitled “Recommenda¬ 
tion for International Standardization of IEEE 
Networking APIs” to the P1224 working group and 
the Distributed Services steering committee. This 
paper recommends the international standardiza¬ 
tion of the IEEE P1224 (X.400 api), POSIX. l7 (Di¬ 
rectory Services api), and P1238 (ftam apis) 
within jtcl/22/WGl5 (iso posix). The Chairman of 
the Distributed Services steering committee will 
forward this recommendation to si (Test and Of¬ 
fice Systems), SC2I (OSi), and SC22 (Programming 
Languages, which includes the iso posix working 
group). 

P1224 Balloting Status 

P1224 is the document defining a network 
object management api, to be used by P1224.1 
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(x.400) and posix.17 (Directory Services). Bal¬ 
loting of the P1224 document began on January 1, 
1992, and it will have ended on January 31,1992. 
The balloting pool consists of 73 members. As of 
the meeting only 5 responses (all yes) had been 
received. The members of the group agreed to call 
the members of the balloting pool to ensure that 
we receive the minimum of 75% responses re¬ 
quired by the ieee for a ballot to close. 

The test methods for P1224 will be included 
in the first recirculation of the P1224 document. 
Balloting cannot complete until the test methods 
are balloted. 

P1224.1 Balloting Plans 

Invitations to join the IEEE P1224.1 Balloting 
group will be sent out immediately after this meet¬ 
ing to: 

• the general tcos balloting pool, 

• members of the x.400 API Association, 

• members of X/Open, 

• members of the Electronic Mail Associa¬ 
tion. 

The P1224.1 balloting period will begin April 
15, 1992 and it will end May 15, 1992. The test 
methods will be included in the initial ballot of the 
P1224.1 document. Iain Devine, the P1224 techni¬ 
cal editor, will be the ballot resolution reviewer, 
assisted in technical matters by members of the 
x.400 API Association and X/Open. The group 
planned the mechanics of the first phase of bal¬ 
loting. 

Test Methods Review 

X/Open funded a contractor to develop the 
test methods for the P1224 and P1224.1 documents. 
This work was completed before our meeting. 

The P1224.1 test methods were distributed to 
the members of the group at the meeting. The 
group spent much of the week reviewing these 
methods, and numerous changes were made. 
When the changes have been incorporated into 
the P1224.1 document, it will be sent to the ieee 
for balloting. 

The P1224 test methods were also distributed 
to the members of the P1224, as well as posix.17. 
The groups spent part of an afternoon reviewing 
them, assisted by a test methods consultant from 


posix.3 (posix Test Methods). When these 
changes, along with the ballot objections and 
comments, have been incorporated into the P1224 
document, it will be sent to the ieee for recir¬ 
culation. 

Report on TAGs 

John Hill <hill@prc.Unisys.com> reports on 
U.S. Standards Technical Advisory Groups: 

Standards, like automobiles, come in several 
sizes, shapes, and colors suitable to the use to 
which they will be put. With cars there are options 
for just about everything from appearance, to 
utility, to emissions control. Not only that, cars 
are also sold with features specifically accommo¬ 
dating the place in which they are to be used. If 
you don’t have a strong grasp of what that means 
then try driving your ’61 Ford Fairlane down any 
London street during crush hour. Your car won’t 
fit, it’s too wide. Its outside mirrors aren’t a 
breakaway type, so you are dangerous to pedes¬ 
trians. Not to mention that you steer on the wrong 
side of the car for the side of the street on which 
you are driving. In London cars have features to 
accommodate their situation, just like your ’61 
Fairlane fits local US requirements in the early 
sixties. 

What does this have to do with standards? A 
lot. The analogy helps highlight some of the prob¬ 
lems of developing worldwide standards. Driving 
and cars provide interesting examples. It would be 
helpful if it were simpler to drive in foreign places 
without being a hazard to the local inhabitants, as 
well as to oneself. What’s more, it would be con¬ 
venient to have the same situation, in terms of 
driving conditions and cars, presented all over the 
world. But in the UK there are unique local re¬ 
quirements for cars, just as there are in all other 
nations of the world. 

Consider the situation. In countries the world 
over, the local people know their driving condi¬ 
tions better than anyone and from them can de¬ 
termine the requirements for a suitable car. After 
all, they face the situation every day. But con¬ 
ditions differ from country to country. This places 
different requirements on the cars to be operated 
in each country. From a producer perspective, 
this results in different product variants to ac¬ 
commodate each country in which the product is 


44 


March/April 1992 



;login: 17:2 


used. From a world user perspective, this results 
in inconvenience during use. (It does, however, 
simplify the matter of determining where you are. 
All you have to do is look at the car you’re 
driving.) From a general interest perspective, it is 
confusing at best and baffling at its worst. 

Information technology exhibits many of the 
same properties as cars. In the case of telecom¬ 
munications, there truly are a multitude of factors 
which take on local values. One trivial example is 
the assignment of characters to numbers on the 
telephone keypad. A tougher problem is the vari¬ 
ability in the quality of phone line service across 
the broad spectrum of transmission rates. Please 
recognize that these examples are objective, de¬ 
terministic, and based on universally accepted 
physical laws and phenomena. Software is, well, 
softer. In any event, there is great interest in 
having a single worldwide standard wherever fea¬ 
sible. 

Standards bodies 

Enter IEC, ccitt and iso. These are the or¬ 
ganizations which develop formal worldwide stan¬ 
dards. Their names are actually French and won’t 
be cited here. It is useful to recognize that, as a 
general characterization of their scopes, they han¬ 
dle electrotechnical (e.g., safety, emi), telecom¬ 
munications (e.g., ISDN) and everything else 
(e.g., food storage, mechanical contraceptive de¬ 
vices, fuels and lubricants) respectively. Devel¬ 
opment of standards for information technology 
spans the traditional boundaries of both iso and 
IEC and, as such, is managed jointly by both iso 
and iec in Joint Technical Committee 1 (JTCl). 

The membership of ISO, IEC, ccitt and JTCl 
is at a higher level than organizations, ccitt is a 
treaty organization; the U.S. is represented by the 
Department of State, ansi represents the U.S. as 
the member body in ISO, the national committee 
in iec, and the national body in JTCl. afnor, bsi, 
sis, DIN and ON, as examples, are the national 
body representatives of France, the UK, Sweden, 
Germany and Austria respectively. Other stan¬ 
dards bodies participate in a limited manner. The 
most visible of these is the regional standards 
developer, the European Computer Manufactur 
ers’ Association (ecma). 

If one were to examine the scope of technical 
activity of JTCl, the unavoidable conclusion is that 


it’s broad and deep. Not only does it cover a lot 
of ground (media to programming languages) but 
it does so in excruciating detail. It is unrealistic to 
expect that a single organization can develop and 
promote a national body position in all the JTCl 
technical activities. In the U.S., the concept of 
Technical Advisory Group (tag) was put forward 
to handle this. 

TAGS 

tags are enabled by ansi to develop the U.S. 
position on a limited set of items for specifically 
identified JTCl activities. What’s that mean? Es¬ 
sentially, that ansi assigns to individual standards 
bodies the responsibility of handling U.S. tech¬ 
nical interest for specific international standards 
activities. 

Most of the time the enabling of specific or¬ 
ganizations to act as a tag for an international 
standards development effort is simple and not 
controversial. Individual programming languages, 
developed in working groups of JTCl subcommit¬ 
tees, are typically simple. For example, there is 
only one U.S. group developing standards for 
posix, IEEE’s P1003, and one for COBOL, x3’s tech¬ 
nical committee, X3J4. As a result, the identifi¬ 
cation of the TAG for those working groups is 
straightforward. 

Sometimes the assignment of tag responsi¬ 
bility is not so easy. Take the example of JTCi’s 
subcommittee on languages, SC 22 . There are sev¬ 
eral U.S. standards development organizations 
which makeup the tag to SC 22 . The ieee has 
posix and Modula-2; codasyl has fims; the De¬ 
partment of Defense has Ada; and X 3 has a mul¬ 
titude of others. Within X 3 , a subgroup manages 
the issues that overlap those tags or that do not 
fall within the activities of any of them. 

As a sidelight allow me to point out that the 
U.S. even needs a TAG to JTCl itself. 

Let’s regroup for a moment. There are tags 
in the U.S. for all levels of iso, iec, ccitt and 
jtci in which the U.S. has an interest. Using JTCl 
as a representative example, this means there are 
tags with responsibility for JTCl itself, for the 
JTCl subcommittees, for the JTCl special working 
groups, for the JTCl technical subcommittees, and 
for the working groups of each JTCl technical 
subcommittee in which the U.S. is interested. If 
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there is activity anywhere within jtci that is of 
interest to the U.S., there is a tag. Someone has 
to do the work. 

Work of TAGs 

A logical question now is “What are these 
tags empowered to do?” Simple question, but a 
complex answer. There are, however, some rules 
of thumb to help out. 

• the more important the decision, the higher 
the U.S. consensus that is required 

• the more detailed and technical the subject, 
the higher the weight given to the opinions 
of technical experts 

Some examples are useful. One action JTCl 
places a heavy value on is the final approval of 
standards. As a result, JTCl rules require that a 
ballot be taken of its members (remember them, 
they’re the representative national standards or¬ 
ganizations) for adopting a document as a world¬ 
wide standard. Similarly, JTCl members must vote 
to approve new work items. One way to think of 
this is that JTCl makes decisions that affect the 
beginning (i.e. approval of new work items) and 
ending (i.e. final approval) for standards. JTCl 
also makes all decisions involving the establish¬ 
ment and dissolution of its immediate subgroups. 

JTCl TAG establishes the U.S. positions on 
matters such as new work items and final approval 
of standards. 

Let us examine a lower level, technical de¬ 
cision of jtci. If we apply the second rule from 
above, we will conclude that the decisions at this 
level are delegated to the working group (of the 
technical subcommittee of jtci). One such deci¬ 
sion is the determination of what text should be 


contained in a draft standard. It doesn’t get much 
more detailed or technical than that. The working 
group determines that all by themselves. 

There is a whole world of gray between the 
two examples cited above. Typically the decisions 
revolve around “recommendations to forward” 
documents in various stages of completion for 
consideration or approval by higher authority 
committees. A complete description of the deci¬ 
sions and recommendations is not really appro¬ 
priate for this article. However, if you’re inter¬ 
ested, allow me to point you to two companion 
documents. 

• the jtci directives (available from ansi) 

• the JTCl tag technical document 1 (avail¬ 
able from cbema) 

They are in the form of procedures but for 
ease of use have comprehensive indices. 

There are a few messages for you to carry 
away. 

• tags are empowered by ansi 

• tags represent the U.S. 

• there are tags for every worldwide stan¬ 
dards activity that is of interest to the U.S. 

• the more important the decision, the higher 
the need for national body consensus; the 
more technical the decision, the lower the 
need for national body consensus 

This has been a brief exposure of technical 
advisory groups in the U.S. As you have ob¬ 
served, the subject is complicated. The best way 
to understand them ,is to join one that is in your 
particular area of interest and expertise. Rather 
than fuss and fret about the problems you see with 
them, it is recommended that you become a part 
of the solution. 
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Automation in the 20th Century 

Michael J. Clark 

[Editor’s Note: I detest voice mail. Recently, I 
have had to deal with a number of vendors whose 
service lines all use it. I have had to endure 10 calls in 
a row to voice mail systems. The part I hate most is 
when you punch through two minutes (at toll-call 
rates!) of menus and then get a busy signal. 

I’m sure the owners of those voice mail systems love 
them. They don’t have to staff anyone to answer the 
phone! I hate them. I want to deal with a person to 
whom I can say, “Accounts receivable” and be ringing 
inside of 2 seconds. Instead, I encounter a litany rem¬ 
iniscent of some old religious chant of “If you want X 
press Y; if you want XX press YY” and so on. It’s 
almost like having to use Macintosh menus via a Touch- 
Tone phone! 

You can imagine, given this dislike, how much I 
enjoyed the following humor piece written by Michael 
J. Clark and appearing in the USENIX newsgroup re- 
c.humor.funny. Michael works at the campus police 
office at Plymouth State College in Plymouth, New 
Hampshire. —RK] 

The setting is a typical bedroom, a woman is 
in the bed asleep, next to her bed is a night stand 
with an alarm clock and a telephone. Suddenly 
the woman awakens to the sound of a strange 
noise in the house. Startled, she looks around, 
starts to panic, and then picks up her phone to call 
the police. 

Woman: (Panicked, talking out loud to her¬ 
self in a low tone) “I-I-I-I’ve got to call the police, 
there’s someone here, oh God I know there is, 
let’s see... what’s the number? (she nervously 
punches the numbers 9-1-1 into the phone). 

After a few rings the phone is answered, 
there is a delay, then we hear: “Welcome to our 
Emergency phone mate 911, the automated emer¬ 
gency answering system, the latest in emergency 
response technology! If you are calling from a 
touch tone phone, please enter a 1 at the tone, 
enter now.” 

The woman looks both shocked and puzzled 
as she nervously punches in a 1. 

Thank you, our Emergency phone mate 911 
recognizes that you are calling from a touch tone 
phone, (long pause) To serve you better your 
police and emergency services have set up this 
system to route your call to the appropriate emer¬ 
gency service personnel, (long pause) If you are 
in need of police assistance enter a 5, if you re¬ 


quire information in Spanish, enter 7, in Chinese 
enter 4, in Greek enter 9, in French enter 6 or 
Italian, enter an 8, if you wish fire or medical 
service enter a 3 and the corresponding numerical 
code for the language in which you will be speak¬ 
ing or in need of translation (long pause) to repeat 
the previous information please enter 0. (long 
pause) Enter your code now please.” 

The woman, who has now gone from fear and 
panic to being irritated and confused enters a 5 
and waits. 

“Emergency phone mate 911 recognizes that 
you have requested police assistance in English, 
(short pause) In order to better serve you, please 
enter the appropriate number at the tone. Enter 
a 1 if your call is not an emergency, a 2 if you need 
information, a 3 if you are returning a call from 
a police official, a 4 if you are inquiring about a 
parking ticket, or a 5 if this is an emergency, enter 
your code now.” 

She shakes her head; rolls her eyes and enters 
a 5 quite forcefully. 

“Emergency phone mate 911 recognizes that 
you have, a police emergency. Please enter a 1 if 
it is a life-threatening emergency, a 2 if it is a 
non-life-threatening emergency, a 3 if there are 
weapons involved, a 4 if there are multiple per¬ 
petrators, a 5 if the perpetrators are non-English 
speaking and will require a Miranda warning in 
any other language. Please be sure to enter the 
appropriate language code if you enter a 5. If the 
police emergency is a non-life-threatening rape or 
physical assault please enter a 7.” 

The woman now has lost her temper, she 
punches in a 2 shouting “How the hell do I know 
if it’s life-threatening or not you imbecile!” 

“Emergency phone mate 911 recognizes that 
you have a police emergency that is non-life- 
threatening. Emergency phone mate will now di¬ 
rect your call to the appropriate department for 
response. Thank you for using Emergency phone 
mate! (long pause) Please hold while your call is 
transferred.” 

She hears ringing. 

A burly voice answers the phone. “Dunkin 
Donuts, may I help you?” 
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COST: USENIX members: $170.00 Non-members: $214.00 - 

California residents add applicable sales tax. - 

Outside U.S.A. and Canada? Add $30.00 for surface postage. - 

Total amount enclosed $- 

*NOTE: Corporate, Educational and Supporting Members of USENIX automatically receive a subscription 
to all proceedings published during their term of membership, which may overlap with this offer. 

PAYMENT OPTIONS 

□ Check enclosed payable to USENIX Association. □ Purchase order enclosed. 

|—| Please charge my: ' , Visa | ] MasterCard 

Account # Exp. Date 


Signature _____ _ _ 

Outside the U.S.A.? Please make your payment in U.S. currency by one of the following: 

* Check - issued by a local branch of a U.S. Bank 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 



Name 


Address 
City __ 


_ State/Country 


Zip /Postal Code, 


Please mail this order form to: USENIX Association 

2560 Ninth Street 
Suite 215 

Berkeley, CA 94710 

The proceedings are shipped within one week of publication. 


This offer is good through 
December 31, 1992 


2560 Ninth Street • Suite 215 • Berkeley, CA • 94710 * 510/528-8649 . FAX 510/548-5738 • office@usenix.org 
March/April 1992 





4.3BSD MAISfUAL REPRODUCTION AUTHORIZATION and 


ORDFR FORM 


Date: ___ 

Pursuant to the copyright notice as found on the rear of the cover page of the UNIX® /32V 
Programmer's Manual stating that: 

"Holders of a UNIX ®/32V software license are permitted to copy 
this document, or any portion of it, as necessary for licensed 
use of the software, provided this copyright notice and statement 
of permisssion are included," 

I hereby appoint the USENIX Association as my agent, to act on my behalf to duplicate and 
provide me with such copies of the Berkeley 4.3BSD Manuals as I may request. 

Signature:_____ 

The prices below include shipping (via UPS) and handling charges for domestic and Canadian orders. 

Overseas Postage only 

4.3BSD User's Manual Set (3 vols) at $28.00 each = $_ $35. each 

4.3BSD Programmer's Manual Set (3 vols) _at $28.00 each = $_ 35. each 

4.3BSD System Manager's Manual (1 vol.) _at $12.00 each = $_ 16. each OR 

Total = $_ $62 for complete set 

Discounts are available for bulk orders. Please inquire. 


PAYMENT OPTIONS 


□ Check enclosed payable to USENIX Association. EH Purchase order enclosed.* 
I | Please charge my: EH Visa EH MasterCard 


Account # 


Expiration Date 


Signature _____ 

* Outside the U.S.A.? Pre-payment is required in U. S. currency by one of the following: 

* Charge (VISA, MasterCard, or foreign equivalent) 

* International postal money order 

* Check -issued by a local branch of a U.S. Bank 


Ship to: 


Bill to, if different: 


Phone:---—- 

Mail your check or purchase order with this order form to: 
USENIX Association, Manual Order Dept. 

2560 Ninth Street, Ste. 215 

Berkeley, CA 94710 _ 


PLEASE ALLOW 3 WEEKS FOR RECEIPT OF YOUR ORDER. 
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MEMBERSHIP INFORMATION 


Any individual or institution may become a member by filling out an application form 
and paying the appropriate annual fee. 


There are five classes of membership: 

Student: $20 

Open to any full-time student at an accredited educational 
institution. A copy of the current student I.D. card must be 
provided. 

Individual: $65 

Open to any individual or institution. Individual Members 
may vote. 

Corporate: $300 

Corporate Membership is open to any individual or 
institution. 


Educational: $160 

Educational Membership is open to accredited educational 
institutions. 

Supporting: $1000 

Open to any individual or institution that wants to support 
the Association to a greater degree than through the Corporate 
Membership fee. 

Corporate, Educational and Supporting members receive all services 
available to Individual Members, plus copies of the proceedings 
from all conferences and workshops that are held during the term 
of membership. 


MEMBERSHIP APPLICATION 


New □ Renewal | 

Name---- 

Address ___ 

City__ State _ Zip_ Country 

Phone __—_ email address: ---- 

□ $20 Student (full-time) L I $160 Educational Institution 

(with copy of LD. card) 1—I $300 Corporate 

C $65 Individual fHI $1000 Supporting 


PAYMENT OPTIONS 

CH Check enclosed payable to USENIX Association. I_] Purchase order enclosed (Educational and Corporate 

I | Please charge my: CH Visa O MasterCard members only). 

Account #--Exp. Date--- 

Signature---- 

Outside the U.S.A.? Please make your payment in U.S. currency by one of the following: 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 

* Check - issued by a local branch of a U.S. Bank 

I I Please send me information on purchasing USENIX Software Distribution Tapes. 

| | Please send me information on purchasing the Second Berkeley Software Distribution Tape (version 2.11). 


USENIX Mailing List 

I I I do not want my address made available to other members. 

I I I do not want my address made available for commercial mailings. 


Mail to : USENIX Association 

2560 Ninth Street, Suite 215 
Berkeley, CA 94710 


March/April 1992 
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Local User Groups 

The Association will support local user groups by doing a mailing to assist the formation of a new 
group and publishing information on local groups in ;login:. At least one member of the group must 
be a current member of the Association. Send additions and corrections to login@usenix.org . 


CA - Fresno: the Central California UNIX Users 
Group consists of a wucp-based electronic mailing 
list to which members may post questions or in¬ 
formation. For connection information: 

Educational and governmental institutions: 
Brent Auemheimer (209) 278-2573 

brent@CSUFresno.edu or csufreslbrent 

Commercial institutions or individuals: 

Gordon Crumal (209) 251-2648 

csufreslgordon 


Richard Martino 

(813) 536-1776 

Tony Becker 

(813) 799-1836 

mcrsysltony 


Ed Gallizzi, Ph.D. 

(813) 864-8272 

e. galizzi@compmail. com 


Jay Ts 

(813) 979-9169 

uunet!pdn!tscs!metran!jay 


Dave Lewis 

(407) 242-4372 

dhl@ccd. harris. com 



CA - Irvine: the UNIX Users Association of 
Southern California meets the 2 nd Monday of 
each month. 

Paul Muldoon (714) 556-1220 

Horizons ext. 137 

Santa Ana, CA 92705 


CO - Boulder: the Front Range UNIX Users 
Group meets monthly at different sites. For meet¬ 
ing schedule, send email to fruug-info@fruug.org 

Steve Gaede gaede@fruug.org 

Software Design (303) 444-9100 

& Analysis, Inc. 

1113 Spruce St., Ste. 500 
Boulder, CO 81 >302 


FL - Coral Springs: 

S. Shaw McQuinn (305) 344-8686 

8557 W. Sample Road 
Coral Springs, FL 33065 


FL - Fort Lauderdale/Miami: The South Florida 
UNIX Users Group meets the 2 nd Tuesday of each 
month. 

Tony Vincent, John McLaughlin (305) 776-7770 
{sun, no vavax, gould}! sunvice! tony 
jmclaughlin@sun.com 

John O’Brien (305) 475-7633 

gatech! uflorida! novavax! john 


FL - Western: The Florida West Coast UNIX 
Users Groups meeting the first Thursday of every 
month. 


FL - Orlando: the Central Florida Unix Users 
Group meets the 3 rd Thursday of each month. 

Mike Geldner (407) 862-0949 

codas! sunfla! mike 

Ben Goldfarb (407) 275-2790 

goldf arb@ hcx9. ucf. edu 

Mikel Manitius (407) 869-2462 

{codas,attmail}!mikel 


KS or MO - Kansas: The Kansas City Unix Users 
Group meetings on the 2nd Monday of every 
month. 

Kansas City UNIX Users Group (KUUG) 

813 B St. (816) 235-5212 

Blue Springs, MO 64015 
mlg@cstp. umkc. edu 


GA - Atlanta: meets on the 1 st Monday of each 
month in White Hall, Emory University. 

Atlanta UNIX Users Group 
P.O. Box 12241 
Atlanta, GA 30355-2241 

Mark Landry (404) 365-8108 


MI - Detroit/Ann Arbor: The SouthEastern Mich¬ 
igan Sun Local Users Group meets jointly with 
the Nameless UNIX Group on the 2 nd Thursday of 
each month in Ann Arbor. 

Steve Simmons home: (313) 426-8981 

scs@lokkur.dexter.mi.us office: (313) 769-4086 

K. Richard McGill Bill Bulley 

rich@sendai.ann-arbor.mi.us web@applga.uucp 
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MN - Minneapolis/St. Paul: meets the 1 st Wednes¬ 
day of each month. 

UNIX Users of Minnesota Robert A. Monio 
17130 Jordan Court pnessutt@dmshq.mn.org 
Lakeville, MN 55044 (612) 220-2427 


MO - St. Louis: 

St. Louis UNIX Users Group Terry Linhardt 
P.O. Box 2182 uunetljgaltstllterry 

St. Louis, MO 63158 (314) 772-4762 


NE - Omaha: meets monthly, 
/usr/group/nebraska Phillip Allendorfer 

P.O. Box 31012 

Omaha, NE 68132 (402) 423-1400 


New England - Northern: meets monthly at dif¬ 
ferent sites. 

Peter Schmitt 

Peter. Schmitt@dartvax! dartmouth. edu 
Kiewit Computation Center (603) 646-2085 
Dartmouth College 
Hanover, NH 03755 


NJ - Princeton: the Princeton UNIX Users Group 
meets monthly. 

Peter J. Holsberg mccclpjh 

Mercer County (609) 586-4800 

Community College 
1200 Old Trenton Road 
Trenton, NJ 08690 


NY - New York City: Unigroup of New York City 
meets every other month in Manhattan. 

Unigroup of New York City 
G.P.O. Box 1931 
New York, NY 10116 

Peter Gutmann (212) 618-0973 

peterg@murphy. com 


OK - Tulsa: the Tulsa UNIX Users Group, $usr, 
meets the 2 nd Wednesday of each month. 

Stan Mason (918) 560-5329 

tulsix! smason@drd. com 

Mark Lawrence (918) 743-3013 

mark@drd.com 


TX - Austin: CACTUS meets the 3 rd Thursday of 
each month. 

Capital Area Central Texas Unix Society 
P.O. Box 9786 
Austin, TX 78766-9786 
ofhcers@cactus.org 

James Johnson (512) 331-3781 

president@cactus.org 


TX - Dallas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
660 Preston Forest, Suite 177 
Dallas, TX 75230 

Kevin Coyle (214) 991-5512 

kevinc@shared.com 


TX - Houston: the Houston UNIX Users Group 
(Hounix) meets the 3 rd Tuesday of each month. 

Hounix answering machine (713) 684-6590 

Bob Marcum, president (713) 270-8124 

Chuck Bentley, vice-president (713) 789-8928 

chuckb@hounix.uucp 


WA - Seattle: meets monthly. 

Bill Campbell (206) 947-5591 

Seattle UNIX Group Membership Information 
6641 East Mercer 
Mercer Island, WA 98040-0820 
bill@celestial. com 


Washington, D.C.: meets the 1 st Tuesday of each 
month. 

Washington Area unix Users Group 
9811 Mallard Drive 
Laurel, MD 20708 

Alan Fedder (301) 953-3626 


CANADA - Toronto: 

Evan Leibovitch (416) 452-0504 

143 Baronwood Court evan@telly.on.ca 

Brampton, Ont. Canada L6V 3H8 
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USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 


SECOND CLASS 
APPLICATION PENDIf 
at Berkeley, CA and 
additional offices 


Postmaster: Send address changes to USENIX Association, 2560 Ninth Street, Ste. 215, Berkeley, CA 9471 
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